[Acess] wat communiceert frontend (mdb) met backend (mdb)

[ErikRo]

Hoi mag ik een beroep doen op jullie jarenlange ervaring en theoretische kennis?
Ik loop tegen een probleem aan wat ik niet kan verklaren ook niet theoretisch en dat irriteert me
mateloos :-)

Bij ons draait een Acces2002 programma (mde), erg mooi, werkt goed is verder niet bijzonder zwaar of ingewikkeld. Scherm bevat wat 6 tabbladen en vulling gebeurt met 6 keuzelijsten en 30 invoervelden, sommige vanuit een gekoppelde tabel.
Het is echter zeer traag. Minimaal 12 sec na klikken op de knop nieuw dossier of open oud dossier. Omgezet naar vb.net duurt het zelfs 28 sec. (ik heb het overigens niet gemaakt :-) )
Jullie snappen het al daar worden de mensen niet vrolijk van.

Dus ik ben eens even wat netwerkverkeer gaan bekijken en het blijkt dat access 2.5mb up en 1.5mb down coummuniceert, kan me voorstellen dat even duurt zeker met meerdere gebruikers. Met vb.net ongeveer 50% extra verkeer.

Nou ben ik geen expert, maar ik had verwacht dat er alleen wat query data over de lijn ging. Maar zeker geen 3 floppies aan data. Maar als ik dit bekijk dan lijkt het wel of hij elke "opening" maar meteen de grafische schermen / opbouw cq tekstvakken en andere opbouwelementen meestuurt. Werkt access misschien zo? Ik had meer verwacht dat er alleen kale ascii data opgehaald werd en dat de frontend dit verwerkt in de al aanwezige grafische elementen.

btw als dat zo is is dat dan ergens uit te zetten?
btw met vb.net hadden ze gehoopt dat het sneller werd maar het werd bijna 2.5 x zo langzaam.

Ik geef toe het is niet de standaard vraag die hier geplaatst wordt maar misschien mag het.

Alvast bedankt voor eventuele tips of info.

[Kuhlie]

Staat de .mdb op een netwerkschijf en 'open' je die in het 'front-end'? Dan komt het daardoor: het is gewoon een bestand waarin gezocht dient te worden en dat gaat allemaal via de netwerkschijf. Je zou een programma op de server moeten draaien waarin je de queries uitvoert en de resultaten ervan over het netwerk sturen. Allemaal niet triviaal trouwens...

[ Voor 5% gewijzigd door Kuhlie op 15-12-2004 22:54 . Reden: tikfoutje ]

[Verwijderd]

ErikRo schreef op woensdag 15 december 2004 @ 21:38:
...
Dus ik ben eens even wat netwerkverkeer gaan bekijken en het blijkt dat access 2.5mb up en 1.5mb down coummuniceert, kan me voorstellen dat even duurt zeker met meerdere gebruikers. Met vb.net ongeveer 50% extra verkeer.

Nou ben ik geen expert, maar ik had verwacht dat er alleen wat query data over de lijn ging.
...
Werkt access misschien zo? Ik had meer verwacht dat er alleen kale ascii data opgehaald werd en dat de frontend dit verwerkt in de al aanwezige grafische elementen.

btw als dat zo is is dat dan ergens uit te zetten?
btw met vb.net hadden ze gehoopt dat het sneller werd maar het werd bijna 2.5 x zo langzaam.

Het zal alleen maar trager worden. En zelfs op enig moment regelmatig 'crashen'.
De traagheid heeft niets te maken met de grafische elementen, maar meer met de techniek van zo'n access-database. In het ergste geval gaan zelfs hele tabellen meerdere malen over de lijn.

De enige oplossing is overstappen naar een echte client/server database.
In dit geval is MSDE (gratis) of Microsoft SQL Server de beste keus. De conversie hiervoor is minimaal.

edit: Wat je nog zou kunnen proberen is om regelmatig de database te comprimeren/repareren

[ Voor 5% gewijzigd door Verwijderd op 15-12-2004 23:47 ]

[ErikRo]

Comprimeren gebeurt al vaak, maar dat maakt helaas qua snelheid niets uit. Hij is wel stabiel want we draaien al een jaar. Andere apps zijn gelukkig wel wat sneller. Maar als ik jullie zo hoor dan wordt het toch echt client server (was ik al bang voor). We hebben wel 80 users (verdeeld over 5 verschillende applicaties, maar gebruik maken van d ezelfde libraries) dus de gratis versie valt af.

Ik vermoed dat dat zoiets geen goedkoop grapje gaat worden? minimaal 500 euro per persoon per jaar of ziets?

Wat voor server denken we hier aan? Een zware pentium of een mainframeachtig iets wat je normaal voor unix/oracle gebruikt?

[ Voor 26% gewijzigd door ErikRo op 16-12-2004 09:11 ]

[P_de_B]

ErikRo schreef op donderdag 16 december 2004 @ 09:07:
Comprimeren gebeurt al vaak, maar dat maakt helaas qua snelheid niets uit. Hij is wel stabiel want we draaien al een jaar. Andere apps zijn gelukkig wel wat sneller. Maar als ik jullie zo hoor dan wordt het toch echt client server (was ik al bang voor). We hebben wel 80 users, ik vermoed dat dat geen goedkoop grapje gaat worden? minimaal 500 euro per persoon per jaar of ziets?

Ongeveer 5000 euro voor een processor license voor MS SQL Server. Ik zou bij 80 users (tenminste als dat gelijktijdige users zijn) inderdaad wel voor een zwaardere database server gaan.

Je kunt gewoon de huidige frontend blijven gebruiken.

[ErikRo]

P_de_B schreef op donderdag 16 december 2004 @ 09:11:
[...]


Ongeveer 5000 euro voor een processor license voor MS SQL Server. Ik zou bij 80 users (tenminste als dat gelijktijdige users zijn) inderdaad wel voor een zwaardere database server gaan.

Je kunt gewoon de huidige frontend blijven gebruiken.

per jaar of eenmalig?

[Theuno]

ErikRo schreef op donderdag 16 december 2004 @ 09:11:
[...]
per jaar of eenmalig?

Je zou natuurlijk ook MySQL (www.mysql.org) als backend kunnen gebruiken. Ook dan kan je dezelfde formulieren e.d. blijven gebruiken.
Dit is een stuk goedkoper en je kan het altijd even proberen of het sneller is. En of het dan wel aan de verwachtingen voldoet.

[P_de_B]

ErikRo schreef op donderdag 16 december 2004 @ 09:11:
[...]
per jaar of eenmalig?

Eenmalig

http://www.microsoft.com/sql/howtobuy/default.asp

(de standard edition is goed genoeg)

[Verwijderd]

80 users, 5 applicaties. Gemiddeld 16 ? Of 5 frontends met een database ? Dat is een hoop voor MS-Access. Access gebruikers zitten elkaar snel in de weg, boven de 10 per database zou ik niet durven.

Verder leest MS-Jet altijd zo veel mogelijk data uit. Voor zoeken helpt een index wel, maar als je een dossier-tabel opent leesttie m waarschijnlijk volledig in.

==> Client/server bouwen