Jullie mening over Access in een multi-user omgeving

[Liesssaa]

Het is gelukt! super bedankt!:thumb:

 

[Floor E]

@Bartuls:

In de meeste gevallen is er aan een formulier of een rapport een module gekoppeld waarin bijvoorbeeld de VBA code die door de verschillende wizards van Access gemaakt wordt voor dat betreffende formulier of rapport geplaatst wordt.
Bij het laden van een formulier in het geheugen van de computer wordt ook deze module meteen geladen.
Door access wordt bijgehouden welke gebruikers welke formulieren en rapporten in gebruik hebben.
Hoe meer gebruikers gebruik maken van een database hoe groter deze overhead voor de access toepassing wordt.
Ook kost het laden van al die losse modules stomweg tijd.
De module die gekoppeld is aan een formulier of rapport is overigens een gewone module, geen class module.

Ik maak formulieren altijd zonder wizard en programmeer vervolgens handmatig alle code onder bijv cmdButtons enz. Als ik jouw reactie goed begrijp dan hoef ik me dus geen zorgen te maken over de performance (dit is nieuw voor me) . Of bedoel je de Microsoft Office Access Klassenobjecten, want daar staat per formulier alle code verwerkt. (ik moet dit nog in de VB cursus uitgelegd krijgen)

Bedankt voor de info! :thumb:

 

[DEWCAP]

Na het lezen van dit onderwerp had ik besloten om mijn DB te splitten. Het splitten ging heel vlot. Maar nu is mijn DB verschrikkelijk traag geworden (terwijl de split juist het omgekeerde effect zo moeten hebben) + sommige gebruikers kunnen de DB niet meer gebruiken. Ze krijgen allerlei foutmeldingen over een Microsoft Jet Database of ze zijn de verschillende subformulieren niet meer. Iemand die hiermee ervaringen heeft? Is het mogelijk een database opnieuw samen te voegen?

 

[gebo51]

Beste Dewcap,

Vreemd dat je deze ervaringen hebt nadat je de db hebt gesplitst. Normaal gesproken mag je helemaal geen problemen hebben, omdat in je _FE alles van de db is opgenomen, behalve je tabellen en in je _BE je tabellen zijn geplaatst.

Je kunt echter simpel de oude (niet gesplitste) situatie terugkrijgen:

1 - verwijder in je _FE de (gekoppelde) tabellen
2- via bestand>externe gegevens ophalen>importeren
3- selecteer je _BE
4-selecteer in het venster 'objecten importeren: alle tabellen en ok
5- Je tabellen uit de _BE zijn nu weer opgenomen in je _FE en je gesplitste db is nu weer een 'enkele db' geworden; je _BE kun je nu verwijderen.

Je zou nogmaals je db kunnen gaan splitsen en kijken of het nu wel goed gaat.
Succes

 

[ReneDirks]

Maar nu is mijn DB verschrikkelijk traag geworden (terwijl de split juist het omgekeerde effect zo moeten hebben)

Waar staat de BE tov de FE? Op een UNC? Gemapte netwerkdrive letter?

 

[DEWCAP]

De _BE en de _FE staan in dezelfde folder op een shared drive op een server. zo het sneller gaan als ik elke gebruiker zijn eigen _FE geef?

 

[ReneDirks]

Dat kan, maar is ook weer niet handig. Ik bedoel mee, hoe link je in de FE naar de BE toe? Staat daar bv \\server\data\database.mdb

 

[Bartuls]

@Floor E

Dat bedoel ik niet.
Aan een formulier of een rapport wordt standaard door access een module gekoppeld.
Die module zie je niet, het is een systeemobject dat altijd verborgen blijft.
Je kunt zien dat aan een formulier of een rapport een module gekoppeld is als bij het betreffende rapport of module de property HasModule de waarde True heeft.
Alle code die je in gebeurtenissen van het rapport of het formulier zet en alle code die je bij de gebeurtenissen van objecten op het rapport of formulier ziet wordt in deze gekoppelde, maar nog steeds verborgen, module gezet.
Zoals jij programmeert komt de code dus nog steeds in de verborgen gekoppelde module terecht.
Deze modules zie je dus niet onder het tabje modules van het database venster, maar ze zijn er wel!

Open je een formulier of een rapport dan wordt eerst de verborgen module gecompileerd en in het geheugen van de computer gezet. Dit kost tijd en vertraagd het openen van het formulier of rapport.

Zet je de eigenschap HasModule op False, dan wordt de gekoppelde echt verwijderd, inclusief alle code die erin staat. Die code is vanaf dat moment dus weg.

Als je de benodigde code in modules (gewone modules, geen class modules) plaatst in functies, dan kun je deze functies aanroepen bij gebeurtenissen van rapporten en formulieren en bij de gebeurtenissen van objecten op rapporten of formulieren.
Dat doe je door: =fnJouwFunctie()

Modules onder het tabje modules van het database venster worden gecompileerd en geladen bij de eerste keer dat er iets uit de betreffende module aangeroepen wordt. Eénmalig dus.

Door bovenstaande techniek toe te passen kun je trage formulieren en rapporten behoorlijjk sneller maken!

 

[DEWCAP]

In de database splitter staat inderdaad het correcte path.

 

[gebo51]

Bartuls
Alle code die je in gebeurtenissen van het rapport of het formulier zet en alle code die je bij de gebeurtenissen van objecten op het rapport of formulier ziet wordt in deze gekoppelde, maar nog steeds verborgen, module gezet.
Zoals jij programmeert komt de code dus nog steeds in de verborgen gekoppelde module terecht.
Deze modules zie je dus niet onder het tabje modules van het database venster, maar ze zijn er wel!

Open je een formulier of een rapport dan wordt eerst de verborgen module gecompileerd en in het geheugen van de computer gezet. Dit kost tijd en vertraagd het openen van het formulier of rapport.

Zet je de eigenschap HasModule op False, dan wordt de gekoppelde echt verwijderd, inclusief alle code die erin staat. Die code is vanaf dat moment dus weg.

Hierover heb ik nog een vraag:

Als ik de property HasModule op 'nee' zet ben ik de code die achter de events van het formulier zit, inderdaad kwijt.
Dus zou ik kunnen checken op de events achter het formulier, en als daar dus geen gebeurtenis is vermeld, kan de property HasModule op 'nee' worden gezet.

Ik heb echter gemerkt dat de code die achter bijv. velden in het formulier zit, wel gewoon blijft bestaan.

Ik zou dus performancewinst kunnen krijgen door de property HasModule op 'nee' te zetten, en daarmee de gebeurtenissen achter de velden kunnen behouden.

So far so good echter,
Code achter buttons op het formulier raak ik wel weer kwijt bij property HasModule op 'nee' .

Kan ik nu stellen:
Alle code achter een formulier ben je kwijt bij property HasModule op 'nee'
Alle code achter velden op het formulier behoudt je met property HasModule op 'nee'
Alle code van buttons op het formulier ben je ook kwijt met property HasModule op 'nee'

Of zitter er nog meer 'addertjes onder het gras'

Bedankt alvast voor jullie reacties