[access] record locking?

Pagina: 1
Acties:
  • 217 views sinds 30-01-2008
  • Reageer

  • Woef
  • Registratie: Juni 2000
  • Niet online
Ik heb een programma gemaakt waar meerdere mensen tegelijk gebruik van maken. Iedereen gebruikt hetzelfde formulier. Alleen het is niet de bedoeling dat ze in dezelfde record zitten te werken. Ik heb het al geprobeerd met record locking alleen dan kan maar een gebruiker dat formulier openen.
Hoe los ik dit goed op? (search enzo allemaal al gebruikt).

  • ATS
  • Registratie: September 2001
  • Laatst online: 12-02 13:46

ATS

Access ondersteunt geen locking op record niveau, alleen op table niveau. Je zal het dus zelf moeten implementeren. Dat is nog niet zo eenvoudig, afhankelijk van hoe ver je wil gaan en wat er nodig is voor je applicatie.

Als je alleen wil voorkomen dat twee mensen tegelijk wijzigingen aanbrengen, dan kan je bijvoorbeeld een extra veld opnemen (ja/nee veld met de naam 'lock'). Voordat je gaat editen controleer je of een record gelocked is. Zo ja, dan mag je niet editen. Zo nee, dan lock je hem zelf, doe je ding, en unlock je vervolgens weer.

Access is overigens inherent niet goed geschikt voor meerdere gelijktijdige gebruikers. Je gaat gegarandeerd meer van zulke problemen krijgen.

My opinions may have changed, but not the fact that I am right. -- Ashleigh Brilliant


  • mocean
  • Registratie: November 2000
  • Laatst online: 30-03 18:32
Staat het gebeuren op een netwerkschijf of zo?

Ik heb zelf gemerkt dat met Access XP hij automatisch het record lockt, wat iemand anders aan het wijzigen is.

Koop of verkoop je webshop: ecquisition.com


  • bille
  • Registratie: Mei 2000
  • Laatst online: 06-05 18:25

bille

Don't call me Buff

Access ondersteunt geen locking op record niveau, alleen op table niveau
imho is dat niet waar. Access kan wél op record niveau locken, daarom kan je dus niet van hetzelfde form gebruik maken met meerdere gebruikers @ the same time. Het betreffende record is gelocked doordat het form is gekoppeld AAN het record dat op dat moment wordt geshowed in het form.

DUS heb je toevallig het form gekoppeld aan een recordset? Zo ja, dan moet je het form niet afhankelijk maken van de recordset maar gewoon een losse querie op de db uitvoeren en de resultset gebruiken om je form te vullen.. en omgekeerd ook, als de gebruikers iets in moeten vullen: een querie samenstellen aan de hand van de ingevoerde data en die uit laten voeren.

http://msdn.microsoft.com...o/html/msdn_adorosest.asp <-zie daar voor meer info over ADO..

ps: ik quote even uit de Access HELP file:
When a user edits a record, Microsoft Access can automatically prevent others from changing that record until the user has finished editing it. Giving one user exclusive access to a record is called locking.
De manier die naar mijn idee het meest correct is: koppel de userinterface los van de database. Maak een aantal objecten (Objectbrokers) die data in de db kunnen manipuleren (R/W). De objectbroker gebruik je in de userinterface om de juiste data op te halen bij de juiste forms en om ook weer data weg te schrijven naar de db.

In softwarearchitectuur (OO) noemt men dit een Façade pattern. Feitelijk wordt jouw objectbroker het enige object dat met de DB kan communiceren (via SQL natuurlijk). Op die manier hou je alle SQL sjit bij elkaar en voorkom je dat je per ongeluk op verkeerde plaasten in de DB gaat lopen klooien.
Access is overigens inherent niet goed geschikt voor meerdere gelijktijdige gebruikers
Kan je daar nog even wat uitleg bij geven aub? Want ook dit is imho onwaar. Access is terdegen instaat om meerdere gebruikers te dienen. Dat er misschien mensen zijn die gewoon niet goed kunnen programmeren en daarom bij 5 users al problemen krijgen.. ala.. dat ligt niet aan Access. Wellicht dat dit wordt veroorzaakt doordat Access een aantal wizards heeft die het wel érg makkelijk maken om iets in elkaar te flanzen, terwijl dat met MySQL wat minder makkelijk gaat waardoor je direct gedwongen wordt tot een ingewikkeldere manier van datatoegang (ODBC).

Access kent uiteraard wel een aantal limits. Als je met grotere datasets gaat werken (lees: > 100.000 records in 1 tabel met 20 kolommen zonder indexen) dan zal het wel allemaal wat trager gaan worden. Tevens is er een ietwat beperkte ondersteuning voor SQL. Het gebruikers limit wordt imho bepaald door de complexiteit van de queries en de frequentie van het uitvoeren van de queries.

[ Voor 105% gewijzigd door bille op 02-12-2003 13:13 ]

Ultra Pilammo 6666Mhz AMD, 4251Mbit/s RAM, Gefors V6666 MegaTurbo, 43" TFS, Ultra 80Gig Firewire netwerkkaart en 5D geluid met 66 speakers in 5 dimensies


  • Bud_s
  • Registratie: Maart 2002
  • Laatst online: 25-05 18:29
ATS schreef op 02 december 2003 @ 12:41:
Als je alleen wil voorkomen dat twee mensen tegelijk wijzigingen aanbrengen, dan kan je bijvoorbeeld een extra veld opnemen (ja/nee veld met de naam 'lock'). Voordat je gaat editen controleer je of een record gelocked is. Zo ja, dan mag je niet editen. Zo nee, dan lock je hem zelf, doe je ding, en unlock je vervolgens weer.
Good old Proggen :) idd extra veldje van type boolean

Ook een fraaie oplossing kan zijn om een extra tabel aan te maken voor de recordlocking.

Dit voorkomt dat je een extra veld in de tabel moet opnemen, en zeker bij tabellen met veel records is dat wel zonde van de ruimte :)

code:
1
2
3
4
5
Bestandsnaam
RecordID
User
Datum
Tijd


Dit geeft je de mogelijkheid om een gebruiker te melden door wie en sinds waneer een record in gebruik is. Tevens kan je in batch alle oude "recordlocks" in een keer verwijderen. Ik neem aan dat de meeste mensen 's nachts niet werken dus je kan 's ochtends alle locks van de voorgaande dag verwijderen. Dit om te voorkomen dat er per ongelijk records gelocked blijven staan als het programma onjuist is afgesloten :)

[ Voor 50% gewijzigd door Bud_s op 02-12-2003 14:51 ]


  • Woef
  • Registratie: Juni 2000
  • Niet online
Wat Bud_s zei heb ik gedaan. Een extra tabel aangemaakt.
Alleen nu moet ik dus een insert query opstellen. Dat is geen probleem. Dat heb ik reeds gedaan. Alleen nu mijn vraag waar zou ik die moet laten uitvoeren (bij welke gebeurtenis)?
En waar de update query dat hij niet meer in gebruik is?

  • Boss
  • Registratie: September 1999
  • Laatst online: 06:28

Boss

+1 Overgewaardeerd

Dit gaat echt nergens over. Zet gewoon record locking aan, en als je het goed doet kan een gebruiker niets wijzigen in een record als een andere er ook tegelijkertijd in bezig is.

Ik heb een paar databases draaien zo (access 97, 2000 en XP) die door 2-15 gebruikers TEGELIJK worden gebruikt. En die kunnen ook in hetzelfde formulier werken, maar dus niet aan hetzelfde record. Hoef je geen regel code voor te schrijven, wel geod de eigenschappen van je formulier en tabellen instellen.

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.


  • Freee!!
  • Registratie: December 2002
  • Laatst online: 07:36

Freee!!

Trotse papa van Toon en Len!

Ruben_Pruim schreef op 04 december 2003 @ 11:13:
Wat Bud_s zei heb ik gedaan. Een extra tabel aangemaakt.
Alleen nu moet ik dus een insert query opstellen. Dat is geen probleem. Dat heb ik reeds gedaan. Alleen nu mijn vraag waar zou ik die moet laten uitvoeren (bij welke gebeurtenis)?
Met een unieke sleutel (tabel, record-id) pal voor het lezen, elementair.
En waar de update query dat hij niet meer in gebruik is?
Direct na het wegschrijven een delete (unieke sleutel weg => lock weg), wederom elementair.

EDIT:
Het volgende vind ik ook beter, maar soms zit je in een bepaalde situatie:
Boss schreef op 04 december 2003 @ 11:25:
Dit gaat echt nergens over. Zet gewoon record locking aan, en als je het goed doet kan een gebruiker niets wijzigen in een record als een andere er ook tegelijkertijd in bezig is.

Ik heb een paar databases draaien zo (access 97, 2000 en XP) die door 2-15 gebruikers TEGELIJK worden gebruikt. En die kunnen ook in hetzelfde formulier werken, maar dus niet aan hetzelfde record. Hoef je geen regel code voor te schrijven, wel geod de eigenschappen van je formulier en tabellen instellen.

[ Voor 38% gewijzigd door Freee!! op 04-12-2003 11:31 ]

The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long

GoT voor Behoud der Nederlandschen Taal [GvBdNT


  • Boss
  • Registratie: September 1999
  • Laatst online: 06:28

Boss

+1 Overgewaardeerd

Mr. Liu schreef op 04 december 2003 @ 11:30:
EDIT:
Het volgende vind ik ook beter, maar soms zit je in een bepaalde situatie:
Zoals ik de situatie hier lees zie ik er echt geen problemen mee. Ik zou TS dan ook afraden om met extra tabellen te gaan werken. Ik heb het idee dat de database niet zo heel erg complex is, en dit zou het alleen maar onnodig verwarrend maken voor ontwikkelaars die later nog iets aan de DB moeten aanpassen.

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.


  • Freee!!
  • Registratie: December 2002
  • Laatst online: 07:36

Freee!!

Trotse papa van Toon en Len!

Boss schreef op 04 december 2003 @ 13:58:
[...]
Zoals ik de situatie hier lees zie ik er echt geen problemen mee. Ik zou TS dan ook afraden om met extra tabellen te gaan werken. Ik heb het idee dat de database niet zo heel erg complex is, en dit zou het alleen maar onnodig verwarrend maken voor ontwikkelaars die later nog iets aan de DB moeten aanpassen.
Ik ben het volkomen met je eens, maar ik denk niet dat het kwaad kan dat de door mij aangegeven methode ook vermeldt wordt, al is het maar voor iemand anders die om een wel legitieme reden tegen dat probleem aan loopt.

The problem with common sense is that sense never ain't common - From the notebooks of Lazarus Long

GoT voor Behoud der Nederlandschen Taal [GvBdNT


  • Woef
  • Registratie: Juni 2000
  • Niet online
Boss kan best wel eens gelijk hebben al de situatie zit zo:

Ik heb een tabel:
belgegevens

Ik heb een formulier:
belformulier

een query gemaakt die alle gegegevens uit de tabel belgegevens haalt en die geef ik weer in het formulier "belformulier".

Vervolgens zet ik bij het formulier recordlocking op "Bewerkte Records", en dan kan ik op de andere computer nog gewoon door alle records heen hoor.

Zet ik recordlocking op "Alle Records", dan komt de ander er niet eens meer in.

Hoe moet ik het wel doen?

  • Bud_s
  • Registratie: Maart 2002
  • Laatst online: 25-05 18:29
zie : [rml]bille in "[ access] record locking?"[/rml]

betreffende de recordset. Als je via je een recordset je gegevens vraagt lcok je dus de *complete* set = meerdere records

  • Boss
  • Registratie: September 1999
  • Laatst online: 06:28

Boss

+1 Overgewaardeerd

En daarom zet je je record lock ook op 'Bewerkte record'.

Die kon je zelf ook wel bedenken, toch? :)

The process of preparing programs for a digital computer is especially attractive, not only because it can be economically and scientifically rewarding, but also because it is an aesthetic experience much like composing poetry or music.

Pagina: 1