[DB]Access ruimt zijn troep niet op

[Verwijderd]

Mij valt wat op. Ik heb zojuist even een app. in elkaar geprutst die afbeeldingen in een access OLE veld wegschrijft. Erg leuk. Probleem is alleen dat als ik een heleboel fototjes inlaad, en de database ongeveer 5 MB is, vervolgens alle records weer wis, de database nog steeds 5 MB is.

Probleem is opgelost als je in Access zelf 'Compact and repair database' onder 'tools' selecteert. Dan is de DB nog maar net zo groot als het aantal plaatjes dat er in staat.

Nou wil ik dit 'purge' commando dus door mijn applicatie laten uitvoeren, en hoopte ik eigenlijk dat dat dan ook met een SQL commando kon. Probleem is dat ik dat commando niet ken, en er ook weinig over kan vinden.

Dus probeer ik de tweak experts maar weer eens uit. Iemand enig idee?

[j_du_pee]

ik heb hier ook ooit naar gezocht. Toen ik nix kon vinden heb ik uiteindelijk een heel ranzig vb-script gemaakt dat mbv sendkeys() deze taak uitvoert.

Dat is geen aanbevelenswaardige oplossing, maar kan wel in geval van nood

_{je kunt in dat geval zoeken naar wscript.sendkeys()}

[Verwijderd]

naar mijn weten geen sql instructie mogelijk, wel opkuis via VBA code.
moest je het niet weten compacten gaat nooit naar de database zelf, wat access doet is compacten naar db1 en terug renamen, dat is wat je ook moet gaan doen...

compacteren:

DBEngine.CompactDatabase databasepath, nieuwpath

terug renamen:

Name nieuwpath as databasepath

grtz
CPUburn

[Verwijderd]

Ik weet wel dat dit kan. Op www.pscode.com staan een aantal voorbeeldjes. Als je er vanmiddag nog niet uitbent, kan ik vanuit thuis wel ff wat code posten . Je moet in ieder geval een of andere vage reference naa Access-en-iets-met-een-X aanzetten, en dan is het daar een of andere methode van... Zie ook sig. voor een directe zoek link

[Verwijderd]

Wow, thanx voor de snelle reacties...

Klinkt alleen wel erg - dat het moet worden gecompact naar een nieuwe database, en vervolgens moet worden overschreven. Gaat de DB vast niet leuk vinden als daar op dat moment nog usertjes in zitten...

Dat sendkeys verhaal, kan je me daar nog wat meer over vertellen? Als m'm DB maar online kan blijven, kan ik dat altijd nog 's nachts laten lopen...

Ik ga nu even pscode leeglurken, hopen dat ik daar wat vind.

[j_du_pee]

Op donderdag 07 maart 2002 16:26 schreef Mammaplank het volgende:
Dat sendkeys verhaal, kan je me daar nog wat meer over vertellen? Als m'm DB maar online kan blijven, kan ik dat altijd nog 's nachts laten lopen...

ik vrees dat daarbij hetzelfde gebeurt. Nl, bij het comprimeren en herstellen wordt de database altijd gelocked..

Is er niet de mogelijkheid de link naar het plaatje in de database op te slaan, en de plaatjes zelf ergens in een directory te zetten?

[Verwijderd]

Op donderdag 07 maart 2002 16:29 schreef j_du_pee het volgende:

[..]

ik vrees dat daarbij hetzelfde gebeurt. Nl, bij het comprimeren en herstellen wordt de database altijd gelocked..

Is er niet de mogelijkheid de link naar het plaatje in de database op te slaan, en de plaatjes zelf ergens in een directory te zetten?

Neuwh, plaatjes mogen niet zomaar door iedereen bekeken worden, privacy bescherming voor de klant. Beschermt ook wat meer, als we de plaatjes in een dir zetten hacked iemand zo een banner logo om naar een ander plaatje, bij een database heb je daar minder kans op, maar het zou wel m'n probleem hebben opgelost.

Ik vraag me alleen af of access ditzelfde grapje niet ook uithaalt met memo velden.

Ik blijf het wel raar vinden, delete record is toch niet delete het maar uit het gezichtsveld maar blijf het toch maar lekker allemaal onthouden Of is dit MS fillisofie?

Ik ga het geheel maar omzetten naar SQL Server 2000 databases, hoop dat ik dan van het probleem af ben.

[Basszje]

Tis idd ook niet een beetje gedaan .. Access is stom

[Verwijderd]

Desnoods kan je aan de snelkoppeling de optie /compact meegeven... Je maakt dan bij de 'gebruiker' twee snelkoppelingen, 1 met je programma en 1 met database-comprimeren.

[Verwijderd]

SQL Server heeft dit probleem ook een beetje... ook daar heb je een compact optie... wel gaat ie gelukkig wat zuiniger om met Access. Bij access heb ik af en toe databases die ik van 100 naar 20 MB kan comprimeren

Voor de volledigheid post ik de code hier toch maar ff. Heeft een toekomstige visitor mischien nog wat aan .

code:

Public Function compactDB(DBPath As String, DBName As String) As Boolean

    On Error GoTo ERR_HANDLER
    Dim JRO As New JRO.JetEngine

    Dim DBSource As String
    Dim DBDest As String

    DBSource = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" _
        & DBPath & "\" & DBName
    DBDest = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" _
        & DBPath & "\temp.mdb" & " ;Jet OLEDB:Engine Type=5"

    JRO.CompactDatabase DBSource, DBDest
    Kill DBPath & "\" & DBName

    JRO.CompactDatabase DBDest, DBSource

    compactDB = True
    Exit Function

ERR_HANDLER:
    compactDB = False
End Function

Je moet hiervoor wel een of andere reference aanzetten waarvan ik de naam ben vergeten...

[Verwijderd]

Kan zelfs nog eenvoudiger, want je kunt gebruik maken van:

code:

DBEngine.CompactDatabase

Hoef je verder geen referenties te zetten. Enige voorwaarde is dat je de database exclusief geopend hebt. Voor details verwijs ik je naar... de Help van Access.

Oh ja, vergeet niet ook af en toe de FrontEnd op te ruimen...

[Verwijderd]

Thanx voor de tips! ( Als je de referentienaam nog kan vinden... ). Ik blijf het errug jammer vinden dat die DB exclusief geopend moet worden. Bewijst maar weer dat access niet in een multi user omgeving gebruikt moet worden.

SQL Server heeft het probleem inderdaad ook, maar dan wel veeeeele malen minder. En ik ben benieuwd wat ie doet met een BACKUP LOG databasenaam WITH TRUNCATE_ONLY

Bedankt in elk geval!