[Access] database gelocked maar niet in gebruik

[Stefke]

Ik heb ergens een database draaien in een netwerkje met een aantal gebruikers. Regelmatig moet ik daar een wijziging op maken, bijv. een veld toevoegen oid, of onderhoud plegen (comprimeren)

Nu is het zo dat vrijwel altijd vanaf de desktopcomputers "verbindingen" open blijven staan (o.i.d.) naar de backend database op de server terwijl de gebruikers alle databases gesloten hebben (al dan niet d.m.v. een access remoteuitlog VBA-scriptje), die er voor zorgen dat ik de database niet uniek kan openen, of zelfs kan onderhouden.

Wat werkt is dat op de server deze verbindingen gesloten worden (windows server beheerfunctionaliteit), ik heb echter zelf geen toegang tot die functionaliteit.

Nu ben ik al de hele avond op zoek naar een oorzaak (en dat is niet de eerste avond , ik heb dit probleem al jaren...), maar ik kom er niet uit. Wat is de oorzaak van die "hangers", kan het zijn dat recordsets in VBA niet goed gesloten worden en daardoor deze links blijven bestaan, ook als de users de database zelf al hebben afgesloten?

Zo heb ik nu zelf de database geblokkeerd, maar ik zit er niet in! En ik zou nu onderhoud moeten plegen, maar nu moet ik morgenvroeg weer contact opnemen met beheer om de links naar het bestand te verwijderen.
Als ik onderhoud pleeg krijg ik de melding dat ik zelf op de gebruikte computer de database in gebruik heb, maar dat klopt dus niet.

De office versie maakt niet uit, en ook de windows versie lijkt niet echt veel uit te maken (ik heb het bij meer klanten)


edit: het lijkt op dit verhaal
http://forums.mysql.com/read.php?65,155679,155679
maar uiteindelijk draait het o.a. om MSJET40-versie, en die is bij mij van het versienummer dat hier genoemd wordt als zijnde de juiste.

[ Voor 22% gewijzigd door Stefke op 20-08-2007 21:47 ]

[Boss]

Dit is gewoon een van de nadelen van Access als back-end. Je kan in ieder geval proberen de .ldb file te verwijderen. Als dat niet lukt heb je gewoon een probleem.

Als ik jou was zou ik serieus overwegen om een database server te gaan gebruiken. Wij doen dit zelf ook alweer een paar jaar (na eerst bij alle klanten gewoon mdb bestanden voor de data gebruikt te hebben) en het scheelt een hoop gedoe.

We gebruiken nu o.a. SQL Server Lite, MSDE en Firebird, allemaal verbonden via ODBC. Nooit meer problemen met gelockte records, comprimeren, corrupte bestanden...

[Stefke]

Jaaaa.....dat moet ook een keer, maar ik kom tijd tekort Ik moet dat eerst nog eens gaan leren en ik heb nu al te weinig tijd om alle mutaties op accessdbs te verwerken.

offtopic:
Ik heb ook het idee dat ik eerst een enorme leercurve doormoet voor ik bijv. een SQL-database fatsoenlijk heb draaien achter mn Access-frontend (zeker met alle zaken omtrent installatie op clientcomputers, de OBDC-koppelingen etc), maar misschien valt het mee?
Heb al eens thuis een MSSQL-server (MSDE) op mijn server gezet, maar de prestaties waren te slecht (PII-servertje) om daar serieus wat mee te doen (ik wist niet eens of de slechte prestatis nu aan de computer lagen of aan mijn broddelwerk ) . Heb nu een nieuwe Core2duo server thuis dus dat is iets wat ik weer op kan pikken, maar dat terzijde.

[ Voor 115% gewijzigd door Stefke op 20-08-2007 21:46 ]

[SKiLLa]

.ldb files zijn altijd X * 64 bytes groot. X is dan tevens het aantal nog 'open staande' recordsets. Indien je openstaande file-handles naar je .mdb wilt sluiten middels VBA zul je je toch moeten richten op het uitvoeren van shell commando's. B.v. de netwerkverbinding disablen/enablen zal je file-handles direct killen. Een beter idee is misschien om SysInternals (gratis, dacht onderdeel van PsTools) 'handle.exe' te gebruiken ...

Maar uiteraard is het droppen van MsAccess de beste oplossing Gewoon naar het gratis MS SQL2005 porten, connectie string aanpassen en (bijna) klaar ben je ...

[Stefke]

SKiLLa schreef op maandag 20 augustus 2007 @ 21:59:
.ldb files zijn altijd X * 64 bytes groot. X is dan tevens het aantal nog 'open staande' recordsets. Indien je openstaande file-handles naar je .mdb wilt sluiten middels VBA zul je je toch moeten richten op het uitvoeren van shell commando's. B.v. de netwerkverbinding disablen/enablen zal je file-handles direct killen. Een beter idee is misschien om SysInternals (gratis, dacht onderdeel van PsTools) 'handle.exe' te gebruiken ...

Maar uiteraard is het droppen van MsAccess de beste oplossing Gewoon naar het gratis MS SQL2005 porten, connectie string aanpassen en (bijna) klaar ben je ...

Filehandles! Dat was t

Het zijn 2 BE-dbs, elk 256bytes groot.

Nou,wat ik op een ander netwerk deed was gewoon effe de share uit- en aanzetten, maar dat leek vorige week hier ook niet te werken. Uiteindelijk heb ik met de beheerder de filehandles uitgezet. Nu hoeft dat niet zo vaak, maar ja, af en toe onderhoud en momenteel toevallig veel mutaties heb ik er regelmatig last van.

[SKiLLa]

Als je de database middels VBA script, moet je er op letten dat je alle ADODB.Recordset en ADODB.Connection objecten zowel .Close() alswel "SET MyAdoDbObject = Nothing" volledig opruimt.

En dat als je Recordset.Connection = gebruikt, gebruik dan "SET objRS.Connection = objConnection" en niet "objRS.Connection = strConnection" of nog erger "objRS.Connection = objConnection".

De oorzaak kan echter ook gewoon het open houden van de MsAccess applicatie (ondanks het sluiten van de DB erin) zijn. Dat is typisch MsAccess.exe gedrag, als je uitsluitend de OLEDB drivers gebruikt (dus puur scripting, zonder de .exe), dan is het uiteraard 100% een code-bug.

[Stefke]

Het enige dat ik doe is recordsets maken

recordset = currentdb.openrecordset("select * from tabel")
recordset.bewerken
recordset.update
recordset.close


Maar waarschijnlijk niet consequent overal alles een .close bij alle aangeroepen recordsets, dus dat moet ik denk ik maar eens gaan doen.

Nu zou ik verwachten dat de oorzaak een scriptje is dat op een getimed form bij de ingelogde gebruiker (om de bijv. 1 minuten) de huidige datum/tijd invult, zodat ik kan zien wie daadwerkelijk de database open heeft staan (omdat alleen dán het tijdveld geupdate wordt), maar juist daar heb ik de .close volgens mij wel redelijk conseqent gebruikt.
De reden dat ik denk dat dat wellicht toch de oorzaak is, is omdat als ik de database open en verder eigenlijk niks doe, de gebruiker dan toch al vrij snel de filehandle open houdt. Dat scriptje start automatisch en onzichtbaar en is dan dus het enige dat actief loopt.

[SKiLLa]

Het is eigenlijk altijd aan te raden om gewoon een db te openen, query uit te voeren en dan direct weer te sluiten en op te ruimen, tenzij je echt meerdere queries per seconde doet. Onder water heb je toch ConnectionPooling en de overhead van de .open is dus minimaal. Vergeet echter de Set ... = Nothing niet, dat is echt vereist om de garbage collector z'n werk goed te kunnen laten doen.

Dus: Open DB zo laat mogelijk en sluit deze zo vroeg mogelijk weer af en ruim altijd alle objecten daarna op met Set = Nothing.

[Stefke]

Zo dan?

set db = currentdb
recordset = db.openrecordset("select * from tabel")

recordset.bewerken
recordset.update

recordset.close
set recordset = nothing
set db = nothing

Overigens is het dan ws. ook niet slim om een recordset als Public te definieren, in te vullen bij het openen van een form, te gebruiken bij de timer en pas te closen bij het sluiten van het form?
Waarschijnljk dus beter om per functie (open, timer, close) de database en recordset apart als variabele te definieren, te openen en te sluiten?

[ Voor 46% gewijzigd door Stefke op 21-08-2007 15:11 ]

[SKiLLa]

Ja, die lokaal - binnen een functie houden - en lokaal opruimen is veel beter.

PS: Indien je troubles houdt, zou je de integrale code kunnen posten, zodat we even kunnen meekijken ...

[ Voor 39% gewijzigd door SKiLLa op 21-08-2007 16:29 ]

[Stefke]

SKiLLa schreef op dinsdag 21 augustus 2007 @ 16:27:
Ja, die lokaal - binnen een functie houden - en lokaal opruimen is veel beter.

PS: Indien je troubles houdt, zou je de integrale code kunnen posten, zodat we even kunnen meekijken ...

Maybe later deze week, beetje druk nu, tnx voor het aanbod