Meerdere gebruikers op één DB

[youri81]

Ik heb een MDB op een gedeelde plek op een netwerk. Hier gaan straks meerdere mensen tegelijkertijd in werken. Ik moet rekening houden met 100+ (ja, daar had ik inderdaad eerder rekening mee moeten houden ).
Ik heb begrepen dat ik dan met problemen krijg te maken, omdat Access bij 15+ personen moeilijk kan gaan doen.

Het programma heeft als doel om enkele gegevens te registreren; het is niet veel data.
De gebruiker heeft twee verschillende mogelijkheden om dit te doen:
- gebruiker opent een formulier dat direct een gezamelijke tabel aanstuurt en plaatst of wijzigt tot zo'n 10 tot 20 waarden.
- gebruiker opent een ander formulier dat een persoonlijke tabel aanmaakt. gebruiker wijzigt 10 tot 20 waarden. na het sluiten wordt de inhoud van de tabel naar de gezamelijke tabel gekopieerd en wordt de persoonlijke tabel verwijderd.

De database werkt met enkele formulieren waar best wel wat VBA-scripting in zit. Bij het openen en sluiten van de twee bovenstaande tabellen wordt de gezamelijke tabel geraadpleegd voordat er zaken worden weggeschreven.
Er is ook een gebruikerstabel die regelmatig wordt geraadpleegd.

Levert bovenstaand verhaal op dit moment problemen op wanneer 100 man tegelijkertijd gaan klikken?
Zo ja, wat zijn goeie aanvliegroutes om dat probleem te omzeilen?

edit: ik ben me ook bewust van het absolute maximum van 255 gebruikers, daar kom ik in elk geval niet aan.

 

[OctaFish]

Heb je de db al ongeveer klaar, of begrijp ik dat verkeerd? En zo ja, in hoeverre kun je er nog aan sleutelen?
Wat ik in jou geval zou overwegen, is om elke gebruiker een niet-gebonden frontend te geven. In die situatie opent een gebruiker een Frontend db, die een connectie maakt met de backend, de tabellen overhaalt, en daarna de connectie verbreekt. Zodra de gebruiker in zijn formulieren iets muteert, en op Opslaan klikt, wordt de connectie geopend, de data opgeslagen en de connectie weer verbroken. In deze situatie heb je dus nauwelijks gebruikers die tegelijkertijd in de db zijn ingelogd, zodat het probleem met grote aantallen gebruikers zo goed als verdwijnt.
Het wordt een klein beetje anders als er hoofdzakelijk gemuteerd wordt in bestaande records, want dan loop je de kans dat meerdere personen hetzelfde record aan het muteren zijn in hun eigen frontend, waarbij je bij het opslaan dus een inmiddels aangepast record kan overschrijven met alweer verouderde gegevens. Dat is aan jou om te beoordelen...

 

[youri81]

Ja, hij is al af ... maar ik moet er toch echt een keer een oplossing voor maken.
Jouw oplossing is wel toepasbaar denk ik. Er worden soms wel bestaande records bewerkt, maar iedereen krijgt zijn eigen. Er komt een username in en in principe mag je alleen die records bewerken.

Kun je me iets meer vertellen over hoe ik die connectie tot stand breng? Is dat met die optie Tabellen koppelen? En dan via VB kopieeren naar een lokale tabel zeker?

 

[Harry46]

Hier gaan straks meerdere mensen tegelijkertijd in werken. Ik moet rekening houden met 100+

Als ik je een goede raad mag geven.
NIET doen in Access al backend!

 

[OctaFish]

Dat zou ook mijn voorkeur hebben; het zou beter zijn om de db te upgraden naar een SQL server-achtige omgeving. Dat kan bijvoorbeeld onze oude vriend MSDE zijn, of SQL Server Express. Beide varianten zijn een goed werkende (gratis) gestripte versie van de commerciele variant Microsoft SQL server.
Het moet uiteraard wel kunnen.... En die beslissing ligt (gelukkig) niet bij ons....

 

[youri81]

Ik moet me beperken tot Access.

Is het zo dat wanneer ik een gekoppelde tabel in de frontend plaats, er geen totaal geen belasting op de backend plaatsvindt, zolang ik die gekoppelde tabel niet open?

Nog een vraag. 100+ is absoluut not done lees ik, maar geldt dat ook voor het slechts open hebben staan van het bestand, met een formulier waarop per persoon eens per zoveel minuten een waarde wordt ingevoerd?
Maakt het verder nog verschil of mensen in één of verschillende tabellen binnen het bestand werken?

 

[OctaFish]

Je moet uiteraard (kunnen) roeien met de riemen die je hebt, en als je niet de beschikking hebt over SQL server, of de db niet kan/mag overzetten naar SQL Server Express, dan is dat het uitgangspunt waarvoor je een oplossing moet zien te vinden. Overigens zou ik toch ernstig kijken naar SQL Server Express; het is gratis, doet (bijna) alles van SQL Server en is relatief simpel te implementeren op een standaard server. Al probeer je het maar eens uit op een kopie van de db...
Om de Access db zoveel mogelijk te ontlasten zou mijn idee dus zijn om iedereen die inlogt met lokale recordsets te laten werken, die alleen connecten op het moment dat er iets moet worden opgehaald of weggeschreven. Doorgaans zijn dat acties die ruim binnen een paar seconden door de frontend worden uitgevoerd, dus je zult maar heel weinig gebruikers hebben die tegelijkertijd in de db werkzaam zijn. En dat laatste is nou net het probleem met Access. Natuurlijk kun je 100 mensen tegelijk laten werken in een db. Alleen gaat de snelheid als een baksteen omlaag, en ook de betrouwbaarheid. Het is niet voor niks dat Microsoft aangeeft dat je maximaal 10-15 man tegelijkertijd in moet laten loggen. En die situatie moet je dus voorkomen.
En dat geldt denk ik ook voor het openzetten van een formulier/record. Op het moment dat iemand een formulier opent, zal hij/zij daarin een record hebben opgezocht. Dat record is op dat moment gelockt voor de andere gebruikers. Doen 100 mensen dat, en proberen ze ook nog eens hetzelfde record te openen, dan kom je echt in de problemen.
Vandaar mijn eerdere vraag wat nu precies de bedoeling is van jouw db/werkwjze. Als mensen alleen gegevens raadplegen dan kun je prima met niet-gekoppelde front-ends uit de voeten. Je koppelt dan bij het inloggen in op de db, haalt alle tabellen over naar de eigen werkplek, en verbreekt vervolgens de connectie met de db. Omdat de brongegevens niet of nauwelijks veranderen, zul je niet snel in de problemen komen.
Anders wordt het als 100 man gaan muteren in de tabellen. Dan krijg je de situatie dat medewerker A de klantgegevens van Klant 123 verandert. Medewerker B heeft de db echter 10 minuten eerder geopend, en heeft dus een verouderde gegevensset op zijn pc. Stel dat medewerker b nu iets anders aanpast voor klant 123. Welk record wordt er dan opgeslagen? Die situatie is dus een heel andere dan een db waarin de meeste mensen alleen gegevens opzoeken.
Kun je daar nog wat meer duidelijkheid over verschaffen?

 

[youri81]

Ik zal proberen kort het doel te omschrijven en hoe de applicatie dit nu afhandelt.

Medewerkers moeten hun productie (aantallen, tot 100 per dag) en urenverantwoording (uutje overleg, half uur project, 4 uur normale werkzaamheden) registreren.
In een tabel wordt voor elke mederwerker per dag een record aangemaakt met, naast de afdelingsgegevens, 42 kolommen met 'activiteiten'. Dit kunnen aantal uren zijn of aantal stuks. Allemaal float.

Het registreren kan op twee manieren, dit kan de gebruiker kiezen.

1. opent een formulier met velden die direct de tabel bestuurt. Als het record van die dag al bestaat, wordt die geopend, anders wordt er een nieuw aangemaakt. Nooit zullen twee medewerkers in hetzelfde record zitten, want ik werk met die Environ-gegevens.
Deze optie wordt door de gebruiker in principe eenmaal geopend om alle gegevns van de dag in te voeren en wordt daarna weer afgesloten.

2. maakt een tabel aan die de naam van de gebruiker krijgt. Een formulier wordt getoont met ook weer velden, alleen hier zitten knopjes bij om gedurende de hele dag bij te houden wat je doet. Bij het verwerken van een stuk klik je op de betreffende knop en wordt er 1 opgeteld. Tijden worden hier ook bijgehouden door switchbuttons. stoptijd-starttijd wordt bij het totaal van die activiteit opgeteld.
Bij sluiten van het formulier worden gegevens gekopieerd naar de hoofdtabel en wordt de tijdelijke tabel verwijderd.
Bij openen wordt ook nog eerst gekeken of er voor die dag al gegevens zijn en die worden dan eventueel van de hoofdtabel naar de nieuw aangemaakte tijdelijke tabel gekopieerd.

Bij 1 zullen niet vaak veel mensen tegelijkertijd werken, maar als veel mensen optie 2 gebruiken hebben die allemaal de appliactie openstaan de hele dag. Er is dan echter wel weinig activiteit.

Goed, kort is niet echt gelukt, maar ik denk dat het verhaal wel duidelijk is.
We hebben overigens vanmorgen enkele stresstests uitgevoerd. De laatste met 35 man die in optie 1 (dus met zn alleen in dezelfde tabel) gegevens invoerden. Verliep zonder merkbare problemen. Optie 2 is nog niet getest.

 

[elvanlim]

Meerdere gebruikers op 1 database

Hallo,

Aansluitend op deze vraag, heb ik ook nog een vraag.

2 van mijn collega's werken met een database (afzonderlijk opgeslagen onder eigen naam) terwijl ze dezelfde werk doen. Aan mij is gevraagd om hiervan 1 database van te maken en toegang te geven voor meerdere gebruikers (10). Een aantal van de gebruikers zitten op een ander locatie. Is het mogelijk dit op een netwerk te zetten, zodat het mogelijk wordt om tegelijk dezelfde database te gebruiken en eventueel muteren? zo ja, wat zijn de eventuele mogelijkheden?

Alvast bedankt voor jullie reacties.

p.s. we werken nog met office 2003

Elvanlim

 

[OctaFish]

@ElvanLim: ik zou hier een eigen topic van maken, want dit is toch een andere vraag.... En het is behoorlijk verwarrend om in iemand anders zijn vraag een zijvraag te stellen.
@Youri81:
Ik denk dat jouw probleem helemaal niet hoeft te bestaan, als je werkt met gescheiden Front-end en Back-end. Zeker niet als je optie 2 gebruikt. Want die lijkt mij meer dan geschikt voor je doeleinden. Overigens kun je nog wel wat verbeteren aan de db, want hij is dus erg slecht genormaliseerd, als je alle activiteiten in één tabel onderbrengt. Veel beter is het om voor die activiteiten een eigen tabel te maken, waarin je registreert wat er echt wordt uitgevoerd. Als iemand 4 activiteiten doet van de 42, hoef je niet meer dan 4 records te maken. Deze constructie is straks ook veel beter als je activiteiten wilt toevoegen, want je hoeft dan de db niet wezenlijk aan te passen. Maar dit terzijde.
Hoe zou ik optie 2 toepassen? Je hebt dus een backend db waarin alle records worden verzameld. Elke medewerker die met de db moet werken krijgt een eigen frontend db. Die kun je in de profielen van de medewerkers zetten, of vast op de werkplekken. In de frontend maak je voor elke persoon die inlogt een aparte tabel aan; dat kan automatisch op basis van de inlognaam. Tevens heb je in die frontend db's een koppeling naar de hoofdtabel uit de backend.
Iedereen werkt op de dag in zijn eigen db met zijn eigen tabel/formulier. Je hebt dus per database één gebruiker, dus je zult nooit problemen krijgen met de belasting op de database; het is een kwestie van één db met één gebruiker. Pas bij het afronden van de activiteiten doe je iets met de backend, want dan moet het record dat gedurende de dag is gemaakt/ingevuld worden toegevoegd aan de backend database. Dat kan uiteraard met een simpele toevoegquery, die het record van die dag toevoegt aan de hoofdtabel. Dit levert nauwelijks belasting op voor de hoofd database, omdat je weliswaar een tabel gekoppeld hebt, maar die wordt gedurende de dag niet geopend/aangeroepen.
Om eerder ingevoerde records te kunnen bewerken kun je nog een extra formulier gebruiken dat is gekoppeld aan de backend tabel. Ook dit formulier zal niet overdreven vaak hoeven worden geopend, omdat oudere records (als ik het goed begrijp) gegevens bevatten die je niet zou hoeven te muteren als je de gegevens goed hebt ingevoerd. Ik neem aan dat je de optie wel beschikbaar wilt hebben, maar eigenlijk ook liever niet...
Zelf zou ik het muteren in bestaande records sowieso niet toestaan, omdat de tijdregistratie nu eenmaal impliciet betekent dat die gegevens vaste gegevens zijn, die later niet meer gewijzigd zouden hoeven worden. Tenzij iemand zijn activiteiten/tijden fout heeft ingevuld op de dag zelf. Daarom zou ik het muteren van de hoofdtabel bij een (aantal) beheerder(s) leggen, zodat je controle houdt over wie wat wenst te muteren. Want er moet wel een goede reden zijn om je tijdregistratie te willen veranderen. En als je dat wel voor iedereen beschikbaar wilt houden, zou ik er toch op zijn minst een historietabel achter zetten, die registreert welke gebruiker wanneer welke velden verandert. Om voorgaande redenen...

Conclusie? Eigenlijk werk je helemaal niet met een BE-FE situatie met 100+ man.....

 

[youri81]

Bedankt voor je uitgebreide antwoord. Ik denk dat ik er nu wel uit ga komen.

Toch nog even ter aanvulling: het is niet zo dat voor 4 activiteiten 4 records worden aangemaakt of zelfs 42. Iedereen krijgt elke dag één record waarin tot 42 verschillende waardes kunnen worden opgeslagen. De niet gebruikte activiteiten blijven lege velden.

Maargoed, wat ik zei, dit is goed uit te voeren. Heel erg bedankt voor je hulp!

 

[OctaFish]

Dat was precies de strekking van mijn verhaal: als je de db gaat normaliseren, dan doe je dat juist wel! Alles van tevoren definiëren is geen goede manier van een db opzetten. Probeer je eens in te lezen in hoe je een db moet normaliseren, want daar heb je later alleen maar voordeel van. Zeker bij deze db...

 

[youri81]

ok, bedankt voor de tip dan, zal ik zeker is doen.