hastighed ved opdeling af db

Hej Ferdinand,

Desværre mister man 10-15% performance på at opslitte databasen på denne måde.
Som du har gjort det nu, så skal du jo kun rette én frontend, da alle brugere benytter den samme. Problemet er ofte bare, at databasen ofte bliver beskadiget på denne måde, ligesom du heller ikke får mulighed for at lave rettelser så længe der er andre brugere på systemet.

Det bedste er at hver bruger får en frontend liggende lokalt på deres maskiner.

Dette giver også en lille smule performance, da hver bruger ikke skal downloade hver formular hele tiden, men har den liggende lokalt.

Hvis du laver ændringer i frontend ofte, kan det være smart at automatisere opdateringen. Det kan enten ske ved Logon-scriptet på hver maskine, eller du kan give hver bruger en .bat-fil, som kopiere den nyeste fil ned på deres maskine (når du har lavet ændringer, sender du så bare en mail til brugerne om at de skal opdatere deres database)

det kan da kun være optimalt, sålænge man ikke skal lave rettelser i front-end'en?! jeg synes det virker som mere end 10-15 %! jeg sidder ofte og venter 10-15 minutter på at få lov at ændre en rapport?! og det er selv om db'en er åben på andre maskiner, eller ej... skal jeg sammenlægge de to igen, indtil der er minimale rettelser, eller ?! hvad er din erfaring?!

Min erfaring er at der ofte kan være væsentligt større svartider, når man splitter databasen op.
Men hvis man ikke gør det, så vil databasen (med tiden) begynde at lave en masse unoder. Hvis en brugers maskine (eller Access) går ned, så opstår der en fejl i databasen som går ud over alle brugere (og data). Dette har kostet data hos flere af mine kunder.
Du risikere også at der opstår låsningsfejl på databasen (også selvom alle brugere er hoppet af!), da Access har lidt problemer med at fungere på denne måde.
Endvidere kan det jo være svært at lave ændringer, hvis andre brugere har f.eks. en given formular åben. Så skal du vente til alle er ude, før du kan lave dine ændringer.

Men omvendt, så vil jeg sige, at hvis du skal bruge 10-15 minutter på at åbne en rapport i design, så er der et eller andet galt.
Jeg ved stort set intet om netværk, men jeg ved at flere af mine kunder, som har oplevet noget lignende, har kunnet føre denne uhensigtsmæssighed tilbage til netværket, som var konfigureret forkert. Efter at have ændret på deres netværksopsætning, blev det væsentligt bedre.
Med netværksopsætning mener jeg ikke indstillingerne på den enkelte maskine, men hele den rækkefølge som serveren levere datapakker efter.

Giver dette mening?

det begynder at dæmre.. jeg løber lige netværket efter i sømmene inden problemerne bliver for alvorlige... med hensyn til front-og backend filer, er det sådan at hvis jeg nu laver en kopi af både front og backend , og lægger overpå en maskine, for at rette i. når jeg så ser stien for de tabeller der ligger i front-end filen, så benytter front-end'en stadig den originale fil på serveren, og ikke den jeg kopierede over på min maskine?! hvordan kan det lade sig gøre?! er der noget jeg har misforstået?!

Ja :o)

Stien til backenden er en Absolut sti (og ikke en relativ sti). Dvs at den bare fordi du flytter Frontenden, så vil den stadig pege på samme backend, indtil du selv sætter den til at pege på en anden.

ok. hvor ved den fra at det lige er dén backend fil den skal pege på? hvis nu jeg fjerner alle genveje til backenden, og lægger tabellerne ind i frontenden, således at db'en nu er en samlet db? er det så nok for at sammenlægge, eller lægger den en masse lort ind alle steder for at pege i den rigtige retning af backenden?

det burde da vist være omkring 15 points værd, hva? :)

Det skulle være nok (du sletter bare alle sammenkædedet tabeller fra Frontenden og importere dem fra backenden)

super... :)

tak for info...