[MS Access] Multi-user omgeving -> db erg snel corrupt? *

[Stefke]

Ik heb ergens een database draaien, MS Access helaas. Ik weet het, Access is niet geschikt voor multiuser omgeving en zo, MS SQL, MYSQL, Oracle blabla is allemaal beter, maar goed, hij staat er zoals ie staat en daar is nu niks aan te doen. Het zou ook niet zo'n probleem zijn, ware het niet dat het maar een kleine database is, en dat deze in mijn ogen extreem snel corrupt raakt

orders: 1349 records
suborders: 2600 records
ordersmemos: 400 records
orderstatus: 6500 records
nog eens 10 tabellen met randinfo: <100 records per tabel

- Databasegrootte na access compressie: 2mb (backend)
- Database bestaat uit een backend op een NT netwerkshare, en elke gebruiker heeft zijn eigen client (access) op zijn computer staan met een verwijzing naar de backend

Gemiddeld 10-12 personen in de database

8 personen die:
- orderstatussen wijzigen (records toevoegen in tabel orderstatus)
- memos ingeven (records toevoegen in tabel memos)

1 persoon die:
- orders en suborders toevoegd en wijzigt
- orderstatussen wijzigen (dmv records toevoegen in tabel orderstatus)
- memos beheren (dmv records toevoegen/verwijderen in tabel memos)

gemiddeld 4 personen uit een groep van 10 die:
- slechts inkijkfunctie, geen wijzigingen of toevoegingen

Het toevoegen, verwijderen en wijzigen van records gebeurt voor 90% via VBA.

Er worden gemiddeld 5 records per dag toegevoegd aan de tabel met memos.
Er worden gemiddeld zon 40 records per dag toegevoegd aan de tabel orderstatus

Elke 4-5 uur raakt de database corrupt . Iedereen die erin zit kan gewoon blijven werken, maar niemand die nog niet in de database zit kan er nog bij. Melding "onbekende database-indeling". Als iedereen eruit is en de database is gerepareerd is het probleem weer weg voor een paar uur. Alleen moet ik daarvoor iedereen op een lompe manier uit de database pleuren (door het uitzetten van de share waar de database op staat).

oke, Access is een kutdatabase, en ik ben bezig om hem op termijn om te gooien naar MS SQL, maar het duurt nog wel even voordat het geheel daarop draait, maar ik snap niet hoe dit zo snel corrupt kan raken. En ik ben er ook nog niet uit hoe ik kan bepalen waar het precies misgaat. Zijn daar wellicht tools voor?

[Creepy]

Heb je iets van locking geimplementeerd? (kan access dat eigenlijk wel?).

Kijk, multiuser LEZEN in access is echt geen probleem. Multi-user tegelijk dezelfde tabel updaten zonder enige vorm van locking is in ELKE database omgeving een probleem.

[Masch]

Ik lees in dit verhaal niks over een backend en frontend?? Dit lijkt mij zeker een goede optie. Zo heb ik hier ook een verglijkend db systeem draaien in access die al maanden goed draait. Misschien moet je ook eens de vba code bekijken, want dat er zo snel corruptie optreed lijkt mij echt niet normaal. Zelfs niet als je geen back-end hebt draaien.

Overigens is SQL geen type database, maar een 'taal'.

[whoami]

Dat is idd het probleem met Access. Die heeft nl. zo geen goed locking mechanisme.

Als ik van jou was, dan zou ik zo snel mogelijk overstappen naar een ander DBMS. MSDE bv, dit is de SQL Server engine die je gratis kan downen.
MSDE ondersteunt wel slechts een beperkt aantal concurrent connecties, maar als je iedere keer je connectie sluit als je ze niet meer nodig hebt mag dat geen probleem zijn.
Ik dacht ergens eens gelezen te hebben dat dat aantal in MSDE 2000 trouwens 25 is, ipv de 5 die het vroeger was.

[Masch]

whoami schreef op 01 maart 2004 @ 14:45:
Dat is idd het probleem met Access. Die heeft nl. zo geen goed locking mechanisme.

Als ik van jou was, dan zou ik zo snel mogelijk overstappen naar een ander DBMS. MSDE bv, dit is de SQL Server engine die je gratis kan downen.
MSDE ondersteunt wel slechts een beperkt aantal concurrent connecties, maar als je iedere keer je connectie sluit als je ze niet meer nodig hebt mag dat geen probleem zijn.
Ik dacht ergens eens gelezen te hebben dat dat aantal in MSDE 2000 trouwens 25 is, ipv de 5 die het vroeger was.

Mhow.. niet helemaal mee eens whoami. Zoals in mijn vorige post te lezen is, is het met een goed front-/back-end systeem best wel te doen (akkoord, het is niet zo stabiel als MSDE ed), access is in mijn ogen best een goed databaseplatform. Het is denk ik heel belangrijk om je tabellen alleen te editten en te updaten als dat echt nodig is (dus alles in 1 x en niet elke regel code een .edit).

[D2k]

Ken het probleem maar al te goed, en als het te groot wordt moeten ze gewoon migreren naar SQL server. nix aan te doen aan die uitgave. Ze hebben jaren geteerd op een el cheapo oplossing en nu moeten ze ff door de zure appel heen bijten.

* D2k heeft een klant die ook eindelijk van een te logge access app naar SQL server + 2 MSDE's gaat

[Stefke]

Masch schreef op 01 maart 2004 @ 14:44:
Ik lees in dit verhaal niks over een backend en frontend?? Dit lijkt mij zeker een goede optie. Zo heb ik hier ook een verglijkend db systeem draaien in access die al maanden goed draait. Misschien moet je ook eens de vba code bekijken, want dat er zo snel corruptie optreed lijkt mij echt niet normaal. Zelfs niet als je geen back-end hebt draaien.
Overigens is SQL geen type database, maar een 'taal'.

Er staat toch wel dat ik een backend op een netwerkshare heb, en elke gebruiker heeft een exemplaar van de frontend op zijn eigen computer.

Ik weet dat SQL een taal is, ik bedoelde MS SQL met de eerste die ik opnoemde, heb t effe gecorrigeerd.

Creepy schreef op 01 maart 2004 @ 14:43:
Heb je iets van locking geimplementeerd? (kan access dat eigenlijk wel?).
Kijk, multiuser LEZEN in access is echt geen probleem. Multi-user tegelijk dezelfde tabel updaten zonder enige vorm van locking is in ELKE database omgeving een probleem.

Er zit wel recordlocking in Access, maar het probleem daarmee is dat die locks vaak blijven hangen. Zeker als je mensen in formulieren rechtstreeks in de tabel laat wijzigen.

Wat betreft het locken en deze database: 90% van de acties die gebeuren betreft het toevoegen van records (orders/suborders toevoegen, statussen toevoegen). Er wordt bijna niet gewijzigd, dus het kan bijna geen locking probleem zijn.

Ik maak veel gebruik van recordsets in de VBA om dus records toe te voegen, maar ik sluit ze meestal niet af (.close). Ik denk dat ik eerst maar eens in elke aanroep van een recordset de database en de recordsets ga sluiten (currentdb.close en rst.close, of set rst = empty). Wellicht blijft ie daar zo vaak op hangen.

whoami schreef op 01 maart 2004 @ 14:45:
Dat is idd het probleem met Access. Die heeft nl. zo geen goed locking mechanisme.

Als ik van jou was, dan zou ik zo snel mogelijk overstappen naar een ander DBMS. MSDE bv, dit is de SQL Server engine die je gratis kan downen.
MSDE ondersteunt wel slechts een beperkt aantal concurrent connecties, maar als je iedere keer je connectie sluit als je ze niet meer nodig hebt mag dat geen probleem zijn.
Ik dacht ergens eens gelezen te hebben dat dat aantal in MSDE 2000 trouwens 25 is, ipv de 5 die het vroeger was.

Ik heb thuis MSDE draaien bij wijze van test en om het e.e.a te leren. Ik moet daarvoor toch wel het e.e.a. ombouwen in de frontend, en daarmee heb ik nog niet zoveel ervaring. Daar gaat dus nog wel wat tijd in zitten.
Verder is MSDE nog steeds geoptimaliseerd voor 5 gebruikers, maar wat dat dan precies inhoudt weet ik niet. Als dat betekent dat er maar 5 gebruikers tegelijk in kunnen werken heb ik niet zoveel aan MSDE. Misschien kan ik dan MySQL of Interbase eens proberen of zo.

[ Voor 14% gewijzigd door Stefke op 01-03-2004 15:03 ]

[gorgi_19]

Masch schreef op 01 maart 2004 @ 14:48:
Mhow.. niet helemaal mee eens whoami. Zoals in mijn vorige post te lezen is, is het met een goed front-/back-end systeem best wel te doen (akkoord, het is niet zo stabiel als MSDE ed), access is in mijn ogen best een goed databaseplatform. Het is denk ik heel belangrijk om je tabellen alleen te editten en te updaten als dat echt nodig is (dus alles in 1 x en niet elke regel code een .edit).

MS Access is nooit gemaakt voor multi-user omgevingen. Dan kan je nog zo goed een front- en backend maken, maar in principe maakt dit laatste zelfs helemaal niet uit.
MS Access gaat makkelijker corrupt dan een SQL Server database of MySQL. MS Access kan best een hoop aan, maar uiteindelijk verliest het qua performance en stabiliteit wel.

Verder kan MSDE, als ik het goed heb, maximaal 5 concurrent connections aan (en zeggen ze op de site: 25 concurrent users voor een webapplicatie, wat wel kan kloppen als je connecties steeds sluit en opent). De rest wordt in een queue geplaatst, zodat je er geen last van hebt.

[ Voor 15% gewijzigd door gorgi_19 op 01-03-2004 15:10 ]

[Masch]

stefijn schreef op 01 maart 2004 @ 15:01:
[...]
Er staat toch wel dat ik een backend op een netwerkshare heb, en elke gebruiker heeft een exemplaar van de frontend op zijn eigen computer.

Ik weet dat SQL een taal is, ik bedoelde MS SQL met de eerste die ik opnoemde, heb t effe gecorrigeerd.

Sorry.... Totaal overheen gelezen.

Er zit wel recordlocking in Access, maar het probleem daarmee is dat die locks vaak blijven hangen. Zeker als je mensen in formulieren rechtstreeks in de tabel laat wijzigen.

Ik zou in geen enkel formulier rechtstreeks wijzigingen laten aanbrengen, maar het altijd dmv recordsets doen zoals je ook aangeeft te doen hieronder

Wat betreft het locken en deze database: 90% van de acties die gebeuren betreft het toevoegen van records (orders/suborders toevoegen, statussen toevoegen). Er wordt bijna niet gewijzigd, dus het kan bijna geen locking probleem zijn.

Ik maak veel gebruik van recordsets in de VBA om dus records toe te voegen, maar ik sluit ze meestal niet af (.close). Ik denk dat ik eerst maar eens in elke aanroep van een recordset de database en de recordsets ga sluiten (currentdb.close en rst.close, of set rst = empty). Wellicht blijft ie daar zo vaak op hangen.

Kun je proberen, maar ik zou het persoonlijk al gelijk na de relevante code doen. Is wel zo netjes (nofi).
Verder nog een tip. Probeer de .addnew .edit en .update, etc zo weinig mogelijk uit te voeren en dus zo consequent mogelijk te gebruiken.

Ik heb thuis MSDE draaien bij wijze van test en om het e.e.a te leren. Ik moet daarvoor toch wel het e.e.a. ombouwen in de frontend, en daarmee heb ik nog niet zoveel ervaring. Daar gaat dus nog wel wat tijd in zitten.
Verder is MSDE nog steeds geoptimaliseerd voor 5 gebruikers, maar wat dat dan precies inhoudt weet ik niet. Als dat betekent dat er maar 5 gebruikers tegelijk in kunnen werken heb ik niet zoveel aan MSDE. Misschien kan ik dan MySQL of Interbase eens proberen of zo.

Qua kosten val je dan veel hoger uit! Wel zal het stabieler worden, maar zoals aangegeven, het kan wel (bij mij @ work in ieder geval).

[Stefke]

Als gebruikers in MSDE in een queue gezet zouden worden is dat ook niet zo erg, want ik weet iig zeker dat er maar weinig "collisions" zijn: zo enorm veel activiteit is er niet in de database (behalve het bekijken van data)

Masch schreef op 01 maart 2004 @ 15:15:

Kun je proberen, maar ik zou het persoonlijk al gelijk na de relevante code doen. Is wel zo netjes (nofi).
Verder nog een tip. Probeer de .addnew .edit en .update, etc zo weinig mogelijk uit te voeren en dus zo consequent mogelijk te gebruiken.

Ik bedoel dat ik dat in de sub of procedure die records toevoegt of verwijderd zelf nog niet echt gedaan heb, en dáár wil ik het doen. Veel eerder na de relevante code kan niet, want dat is aan het einde van een uitgevoerde sub.

En dat .edit en zo, ik doe dat ook echt alléén op het moment dat gegevens ingevoerd worden. Waar anders? Iig niet dat ik .edit laat uitvoeren en dan nog een berg code uitvoer en uiteindelijk de benodigde gegevens doorgeef.

Qua kosten val je dan veel hoger uit! Wel zal het stabieler worden, maar zoals aangegeven, het kan wel (bij mij @ work in ieder geval).

Gezien de geringe databasegrootte lijkt het mij dat deze dbase het toch ook wel een paar dagen moet uithouden zonder naar de klote te gaan...

[ Voor 11% gewijzigd door Stefke op 26-11-2004 20:55 ]

[Masch]

stefijn schreef op 01 maart 2004 @ 15:29:
Als gebruikers in MSDE in een queue gezet zouden worden is dat ook niet zo erg, want ik weet iig zeker dat er maar weinig "collisions" zijn: zo enorm veel activiteit is er niet in de database (behalve het bekijken van data)


[...]

Ik bedoel dat ik dat in de sub of procedure die records toevoegd of verwijderd zelf nog niet echt gedaan heb, en dáár wil ik het doen. Veel eerder na de relevante code kan niet, want dat is aan het einde van een uitgevoerde sub.

En dat .edit en zo, ik doe dat ook echt alléén op het moment dat gegevens ingevoerd worden. Waar anders? Iig niet dat ik .edit laat uitvoeren en dan nog een berg code uitvoer en uiteindelijk de benodigde gegevens doorgeef.

[...]

Gezien de geringe databasegrootte lijkt het mij dat deze dbase het toch ook wel een paar dagen moet uithouden zonder naar de klote te gaan...

Idd het geval, uitzonderlijke situatie heb je daar.

Over de .edit. Als je een kwartje kreeg voor iedereen die dat doet, dan was je inmiddels wel miljonair. Ik bedoel dit soort constructies;

code:

if waar = waar then
  .edit
  'wijzigingen uitvoeren
  .update
else
  .edit
  'wijzigingen uitvoeren
  .update
end if

'en daarna nog een keer vrolijk;

if waar2 = waar then
  .edit
  'wijzigingen uitvoeren
  .update
else
  .edit
  'wijzigingen uitvoeren
  .update
end if

Dit deed mijn voorganger hier dus overal, met als gevolg een ontzettende trage db die vaak corrupt raakte en ik uiteindelijk zlefs helemaal van scratch af aan ben begonnen.

[Stefke]

?

Dat kun je toch niet echt anders oplossen dan zo?

[Masch]

Jawel,

Ik doe het hier nu op de volgende manier;

code:

.edit
if waar = waar then
  'wijzigingen uitvoeren
else
  'wijzigingen uitvoeren
end if

if waar2 = waar then
  'wijzigingen uitvoeren
else
  'wijzigingen uitvoeren
end if
.update

[Stefke]

mke. Zou het niet zo zijn dat je records langer in bewerking zijn omdat je m eerst openzet, dan allerlei IFs uitvoert, en dan afsluit?

Of gebeurt er iets anders waar ik geen weet van heb

[ Voor 18% gewijzigd door Stefke op 02-03-2004 09:12 ]

[Masch]

Tja, dat is wel waar natuurlijk. Maar de praktijk hier heeft uitgewezen dat dit corruptie wel degelijk tegen gaat. Het is natuurlijk ook zo dat de gebruiker hier niet veel van merkt. Die code gaat toch supersnel. Ik denk dat je er wel degelijk baat bij hebt als er maar 1 update wordt uitgevoerd ipv een groot aantal.

Misschien dat er nog andere tweakers zijn die hier iedeeen over hebben? Ik kan eigenlijk geen bewijzen oid vinden voor mijn stelling, anders dan de praktijk hier.

[Stefke]

Ik heb meer zoiets:

code:

van 1 tot X
    .addnew
    velden = waarden
    .update
Loop

Er moet dan namelijk bijvoorbeeld voor elke geselecteerde order een status toegevoegd worden.

Dan krijg je dus dat ie X keer snel achter elkaar een record toevoegt. Er van uitgaande dat de reden dat jouw database niet snel corrupt gaat ook daadwerkelijk hetgeen is dat jij omschrijft, hoe zou ik dit dan anders kunnen doen.

[ Voor 3% gewijzigd door Stefke op 02-03-2004 13:14 ]

[TukkerTweaker]

Recorsets afsluiten na gebruik kan een hoop gezeur schelen. Ik heb een multi-user access omgeving in gebruik (+/- 10 gebruikers) die behoorlijk wat groter is dan jouw database. Bijna geen last van corrupte databases.
Als een record door een andere user in gebruik is komt access keurig met een alleen lezen meldig

[Stefke]

OMFG, een dieptepunt. Een uur heeft het geduurd voor ie weer corrupt was. Rot op zeg

[JJvG]

Ik ben zelf Access ontwikkelaar en heb ook diverse soortgelijke problemen gehad met Access. De situatie die bij mij de voorkeur heeft en die ik je bij deze dus aanraad is:

- Houdt data en voorkant gescheiden (zoals je hebt), en dan bij voorkeur in een SQL server, ivm backups en eenvoudiger beheer.
- Maak een MDE (gecompileerde versie) van de je MDB voorkant, dan raakt-ie een stuk minder snel corrupt. Bewaar je originele MDB voor ontwikkeling (in een DEV directory ofzo, zodat je de source aan kan passen.

Ben benieuwd of dit bij jou ook een positief resultaat heeft.

[Stefke]

Nee , want zover was ik ook al lang (frontend, backend, .mde). Het is niet de frontend die corrupt raakt, alleen de backend.

[TukkerTweaker]

stefijn schreef op 02 maart 2004 @ 13:53:
OMFG, een dieptepunt. Een uur heeft het geduurd voor ie weer corrupt was. Rot op zeg

ik denk niet dat je probleem in de code zit die je oplepeld, als het zo snel gaat dan is er een ander probleem. Sluit je de recordsets wel goed af? Hoe is je netwerkverbinding?

[Stefke]

Hoe sluit je een recordset af dan? recordset.close?

Dat heb ik vandaag overal ingevoerd (want dat had ik niet overal gedaan), en het lijkt (maar dat is natuurlijk niet zo, dat weet ik wel) nu nog wel erger te zijn. Zojuist na <2 uur weer vast.

Hoe zou ik kunnen uitsluiten dat het het netwerk is? Er zitten hier in het bedrijf vanaf zo'n 30 werkplekken gemiddeld 10-12 mensen in de database. Sommige zitten op >150 meter verwijderd van de server, kan me voorstellen dat niet alle verbindingen optimaal zijn.

[TukkerTweaker]

stefijn schreef op 02 maart 2004 @ 15:07:
Hoe sluit je een recordset af dan? recordset.close?

ja

Dat heb ik vandaag overal ingevoerd (want dat had ik niet overal gedaan), en het lijkt (maar dat is natuurlijk niet zo, dat weet ik wel) nu nog wel erger te zijn. Zojuist na <2 uur weer vast.

Hoe zou ik kunnen uitsluiten dat het het netwerk is? Er zitten hier in het bedrijf vanaf zo'n 30 werkplekken gemiddeld 10-12 mensen in de database. Sommige zitten op >150 meter verwijderd van de server, kan me voorstellen dat niet alle verbindingen optimaal zijn.

Testen kun je doen door grote bestanden op te halen maar vooral ook weg te schrijven.

[Stefke]

Nja, oke, maar die komen wel aan hoor...ik zou eigenlijk dan een of andere tool moeten hebben die echt kan testen.

[WimB]

stefijn schreef op 02 maart 2004 @ 13:13:
Ik heb meer zoiets:

code:

van 1 tot X
    .addnew
    velden = waarden
    .update
Loop

Er moet dan namelijk bijvoorbeeld voor elke geselecteerde order een status toegevoegd worden.

Dan krijg je dus dat ie X keer snel achter elkaar een record toevoegt. Er van uitgaande dat de reden dat jouw database niet snel corrupt gaat ook daadwerkelijk hetgeen is dat jij omschrijft, hoe zou ik dit dan anders kunnen doen.

Kan je niet veel beter een SQL-instructie sturen in de zin van:

code:

INSERT INTO ... VALUES ...

in plaats van met .addnew en .update te werken.

Volgens mij legt jou systeem langer beslag op de database.

Verder wil ik ook nog vragen of je de laatste Service Pack van Access hebt geïnstalleerd.

[WimB]

Nog een opmerking: Je formulieren zijn toch niet gekoppeld aan een tabel?

[Stefke]

Dat gebruik maken van SQL is zowieso beter als ik straks naar een SQL-server toe ga werken niet?

Er is 1 formulier dat gebaseerd is op een tabel, maar dat formulier wordt maar door 1 gebruiker gebruikt (het ingeven van suborders). Dat gebeurt zo'n 30x per dag schat ik.
Ook dat zou toch niet zo'n probleem moeten zijn, ook al verdient het misschien geen schoonheidsprijs.

[Verwijderd]

I hoor niemand praten over oppertunistic locking

http://www.samba.org/samba/docs/man/locking.html#id2922156
http://support.microsoft....aspx?scid=kb;en-us;173006
http://support.microsoft.com/?id=812937
http://support.microsoft....spx?scid=kb;en-us;Q129202
http://support.microsoft....spx?scid=kb;en-us;Q224992

JO

[Stefke]

Hmm..de backend staat op een NT4 server. Misschien moet ik op de server en de clients die regoptie maar eens inzien

All Windows operating systems in the NT family that act as database servers for data files (meaning that data files are stored there and accessed by other Windows PCs) may need to have opportunistic locking disabled in order to minimize the risk of data file corruption. This includes Windows 9x/Me, Windows NT, Windows 200x, and Windows XP. [4]

If you are using a Windows NT family workstation in place of a server, you must also disable opportunistic locking (oplocks) on that workstation. For example, if you use a PC with the Windows NT Workstation operating system instead of Windows NT Server, and you have data files located on it that are accessed from other Windows PCs, you may need to disable oplocks on that system.

SYMPTOMS
Under extreme conditions, some multiuser database applications that use a common data store over a network connection on a file server may experience transactional integrity issues or corruption of the database files and/or indexes stored on the server. This typically applies to some so-called "ISAM style", or "record oriented" multiuser database applications, not to a client/server relational system like SQL Server.
CAUSE
If a multiuser or single user database application accesses a common data store on a Windows NT file server using opportunistic locks (or OPLOCKS), it is possible for a given user to cache partial transactions on the client systems hard drive. This is a performance enhancement to the Windows client redirector to reduce network file I/O between the client and server. The data being cached on the client redirector is later written back to the server. However, in some cases, a client system may stop responding (hang), do a hard reboot, lose its network connection to the server, or experience any number of other technical difficulties. In such cases, the content of the local cache that has not yet been written to the server can be lost. As a result, the transaction integrity of the database structures on the server is compromised and the data on the file server can become corrupted.

Als er maar iets een beetje helpt dan is het al wat. Op dit moment slaat de database wel 4 a 5x per dag vast, en dat is op zich niet zo'n ramp, want het is binnen 5 sec weer gefixed, alleen het is voor de gebruikers gewoon kut want ik moet de gebruikers die er dan nog inzitten (en die gewoon kunnen werken) hardhandig uitpleuren

[ Voor 100% gewijzigd door Stefke op 03-03-2004 14:01 ]

[Stefke]

Ik heb op de server (NT4) Oplocking uitgezet. Effe afwachten of het helpt. Ondertussen ben ik eigenlijk ook wel van mening dat het bijna niet meer aan het prog kan liggen....denk dat ik het toch ook in het netwerk ga zoeken als dit niets helpt.

[TukkerTweaker]

Dat de bestanden aankomen geloof ik wel maar gaat dit ook conform de snelheid (10/100Mbit).
En inderdaad meer sql toepassen, docmd.runsql toepassen.

[Stefke]

Vanmorgen was de database rond 8.30 weer corrupt. Heb daarna rond 9.30 de registry aangepast van de server (OpLocksenabled = 0) en vandaag is er geen corruptie opgetreden! Terwijl dit de laatste paar dagen 4 a 5x per dag gebeurde...

Nog effe aankijken (en een keer terugzetten en kijken of het probleem dan weer terugkomt - voor zover het al weg is) en dan lijkt het er toch wel op dat dat de oplossing was

[ Voor 8% gewijzigd door Stefke op 03-03-2004 19:19 ]

[Verwijderd]

stefijn schreef op 03 maart 2004 @ 19:18:
Vanmorgen was de database rond 8.30 weer corrupt. Heb daarna rond 9.30 de registry aangepast van de server (OpLocksenabled = 0) en vandaag is er geen corruptie opgetreden! Terwijl dit de laatste paar dagen 4 a 5x per dag gebeurde...

Nog effe aankijken (en een keer terugzetten en kijken of het probleem dan weer terugkomt - voor zover het al weg is) en dan lijkt het er toch wel op dat dat de oplossing was

ACC2000: How to Troubleshoot Corruption in a Microsoft Access Database
ACC97: How to Troubleshoot Corruption in a Microsoft Access Database

Het uitzetten van "de oplocks" kan de performance nadelig beinvloeden.
Is het een 'traag' netwerk?
Wie gebruiken er allemaal je applicatie als corruptie optreedt?
Defecte netwerkapparatuur?
Wellicht kun je iedere keer een pc/gebruiker van een applicatie uitsluiten, om zo het probleem te lokaliseren.

Ik zou toch maar alvast beginnen met het omzetten van je programma naar een andere database. Vroeg of laat treedt er weer corruptie op (edit: en is deze niet meer te repareren)

[ Voor 3% gewijzigd door Verwijderd op 03-03-2004 19:51 ]

[Stefke]

Ik was al bezig, maar dat duurt nog wel effe.

Overigens wordt elk half uur een backup gemaakt, en die werkt ook niet als de database corrupt is, dus ik heb altijd de laatste versie, max 30 minuten oud.

Er is trouwens weinig van de merken, van die performance loss

[ Voor 14% gewijzigd door Stefke op 03-03-2004 21:44 ]

[Verwijderd]

stefijn schreef op 03 maart 2004 @ 21:43:
Ik was al bezig, maar dat duurt nog wel effe.

Overigens wordt elk half uur een backup gemaakt, en die werkt ook niet als de database corrupt is, dus ik heb altijd de laatste versie, max 30 minuten oud.

Er is trouwens weinig van de merken, van die performance loss

Het kopieren van de database als deze nog open staat is vragen om problemen. Dit kan namelijk ook corruptie veroorzaken.
Dit geldt trouwens niet alleen voor Access, maar een algemeen iets.

[ErikRo]

Bij ons wordt al jaren in access97 ontwikkeld en we hebben nog nooit een corrupte DB gehad. Backend, frontend en een MDE maken. Vraag me alleen niet hoe, nooit problemen. Maar het kan dus wel. Access ondersteund ook diverse methoden van locking. Succes in ieder geval.

ps omdat het zo'n succes is, wordt oa wegens geldgebrek bij ons, nu zelfs al gesproken om een CRM systeem met Access te gaan ontwikkelen voor +/- 150 gebruikers!
Zoveel vertrouwen hebben ze erin.

Persoonlijk zou ik het ze afraden (maar dat is meer een gevoel). Aan de andere kant houd ik wel van een praktijkvoorbeeldje

[ Voor 6% gewijzigd door ErikRo op 03-03-2004 23:45 ]

[Creepy]

ErikRo schreef op 03 maart 2004 @ 23:43:
Bij ons wordt al jaren in access97 ontwikkeld en we hebben nog nooit een corrupte DB gehad. Backend, frontend en een MDE maken. Vraag me alleen niet hoe, nooit problemen. Maar het kan dus wel. Access ondersteund ook diverse methoden van locking. Succes in ieder geval.

ps omdat het zo'n succes is, wordt oa wegens geldgebrek bij ons, nu zelfs al gesproken om een CRM systeem met Access te gaan ontwikkelen voor +/- 150 gebruikers!
Zoveel vertrouwen hebben ze erin.

Persoonlijk zou ik het ze afraden (maar dat is meer een gevoel). Aan de andere kant houd ik wel van een praktijkvoorbeeldje

Het ligt er maar net aan wat je mee doet. Ik weet dat een bepaalde grote site ruimte biedt voor "derden" om met een klein CMS een eigen site in die grote site te hangen. Meer dan 150 van die kleine sites draaien er zonder problemen. En dat allemaal met een access DB.

[Stefke]

Verwijderd schreef op 03 maart 2004 @ 23:15:
[...]

Het kopieren van de database als deze nog open staat is vragen om problemen. Dit kan namelijk ook corruptie veroorzaken.
Dit geldt trouwens niet alleen voor Access, maar een algemeen iets.

Dat is niet de reden van corruptie in dit geval, want dat gebeurde ook al net zo erg voor het backuppen.
Daarbij is het een access-backuptool (Access autopilot), die maakt exports naar een andere .mdb en zipt deze naar een lokatie, geen simpele kopie van de mdb dus.

[Stefke]

Sinds woensdagochtend is de database niet meer vastgelopen. De enige wijziging die ik aangebracht heb ik de server-registry entry voor het uitzetten van Oplocks.

Dank u voor de ti p. Los van het feit dat een SQL-server beter zal werken in het algemeen draait de database nu blijkbaar wel stabiel genoeg

[Verwijderd]

Toch nog een klein tipje. MSDE kun je heel mooi met Access ontwikkelen en is veel beter in multi-user. Kies in plaats van een standaard .mdb voor een .adp. Dit geeft je alle voordelen van beide werelden (Access en SQL server).
Oh ja, nog een tipje wat betreft updates/inserts:
Werken (andere acties als lezen dus) op de recordset geeft in Access een pagelock. Je kunt Access op RecordLock zetten maar beter is het om dit alles te vermijden. Pleur alle db-acties die je in 1 keer wilt uitvoeren middels SQL-statements in een transactie.

[Stefke]

inmiddels nog steeds een stabiele access database zonder 1 vastloper in de afgelopen weken