All tests are fines !

I made test with an accdr connected by the network on a huge backend.

No problemo I give the code to a french forum.

Bye

It seems that it works as for self updating access frontend !

the first tests are good !

It’s great !!

Thanks

bHandleCompactOnExit
Restarter.Restart Compact:=False

Best regards Martin

'Usage in conjunction with the Restarter:
'Restarter.Restart Compact:=bHandleCompactOnExit()

'And for the AutoExec macro or startup form:
'RestoreAutoCompactSetting

'You also need a table with the fields Parameter and Value _
    and a record where Parameter='CompactOnExit'.
    
Public Function bHandleCompactOnExit() As Boolean
''Compact on exit' might need to be shut off, if so, save current setting _
    and shut off. Use code at application startup (i.e. the AutoExec macro _
    or starter form) to restore 'Compact on exit'.
Dim iAutoCompact As Integer
    
    'get setting
    iAutoCompact = AutoCompactSetting
    
    'Store the value in a way that it is available at next startup.
    DoCmd.RunSQL "UPDATE LocalSettings SET LocalSettings.[Value] = '" _
        & iAutoCompact & "' WHERE (((LocalSettings.Parameter)='CompactOnExit'));"
        
    If iAutoCompact = True Then _
        AutoCompactSetting = False
        
    bHandleCompactOnExit = iAutoCompact
    
End Function

Public Sub RestoreAutoCompactSetting()
'Restore previous setting for 'Compact on exit'. Call this sub from _
    AutoExec macro or your startup form.
    
    'Get previously saved setting and set it for your application
    AutoCompactSetting = DLookup("Value", "LocalSettings", _
        "Parameter = 'CompactOnExit'")
    
    'Save a value for next startup that does not _
        affect 'compact on exit'
    DoCmd.RunSQL "UPDATE LocalSettings SET LocalSettings.[Value] = '1' " _
        & "WHERE (((LocalSettings.Parameter)='CompactOnExit'));"

End Sub

Public Property Get AutoCompactSetting() As Integer
'Get current setting for 'Compact on exit'

    AutoCompactSetting = Application.GetOption("Auto Compact")
    
End Property

Public Property Let AutoCompactSetting(iOnOffVoid As Integer)
'On/Off for 'CompactOnExit' _
    iOnOffVoid decides: True (-1) 'CompactOnExit' on _
                      False (0) 'CompactOnExit' off _
                      else (e.g. >0) no change
                      
    If (iOnOffVoid = True) Or (iOnOffVoid = False) Then _
        Application.SetOption "Auto Compact", iOnOffVoid
        
End Property

Thinks you can try:

• make sure you have the PING command. It should be there, but open a command prompt and check that it’s installed.
• Try to change the wait duration for the PING command in the VBA code for Restart():
  Change the line that contains:
  ping 0.0.0.255 -n 1 __-w 100__ > nul to
  ping 0.0.0.255 -n 1 __-w 1500__ > nul

I get the following error:

“Could not use ‘Z:\Project Metrics\Project Metrics -test.mdb’; file already in use”

I assume this is because it tries to open the database too quickly is this the case and if so can be further slowed down?

Dear can u help me to solve this question? I hope to listen from you soon.

Thanks

It’s is not recommended to use ‘Auto Compact’ in shared environments\over networks etc. -- see this thread (which basically confirms my own findings): http://www.utteraccess.com/forums/showflat.php?Cat=&Number=603048&Main=601621

Compacting is a delicate process, which should be executed with ‘care’ -- only in a stable environment (local), making a backup first etc. (ok, I don’t always do that myself either, but we all should…).

So, compacting from code (http://www.mvps.org/access/general/gen0041.htm), you know when it is finished as it returns the result (http://msdn.microsoft.com/en-us/library/ms696119.aspx) -- after that you could use Renaud’s batch file to restart.

This thread contains some code to compact when your MDB reaches a certain size: http://www.tek-tips.com/viewthread.cfm?qid=642227

And here some sleeker code tha gives the user 3 options: http://forums.devarticles.com/microsoft-access-development-49/compact-database-via-vba-24958.html

I haven’t tested all the code, so don’t shoot the messenger…

  Dim compactonclose As Variant
    compactonclose = Application.GetOption("Auto Compact")
    If compactonclose Then
        MsgBox "I am set to compact on close"
  End If

The above routine will detect if compact on close is selected. As for detecting when the database has actually closed, still working on that. I’ll keep you posted.

I’ll see what can be done. My guess would be to try to detect whether the database is set to compact on close and find a way to detect when access has completed the compacting process.

Thanks, Lu

The test database for restarting the application is now available in Access2007 and Access2000 versions.
If someone could test the MDB version and let me know if it works properly or not I’d be grateful.

A few comments:

1) I realise you work with Access 2007 (with new extensions) -- all previous versions use .mdb for the DB itself and .ldb for the lockfile -- by adding the ‘l’ in line 3, it doesn’t work for older versions (it should replace the ‘m’) -- any idea how to make it generic?

1a) Say you run a DB in execute-modus (extension = .accde) -- then looking for the ‘l’+'accde’-file is not going to work, as the lockfile will still be ‘.laccdb’ -- right?

2) When Access crashes, it doesn’t delete the lockfile -- in case you run this batchfile and the .ldb not being removed, you end up in an infinite loop -- not a resource-hog, I assume, but on creating this batchfile again (on restarting Access), you might run into trouble, as the previous batchfile is still present and you can’t create a new batchfile with the same name. Perhaps you should build in some timer that self-deletes the batch file (after 2 minutes). And give batchfiles an unique name (e.g. incl. a timestamp).

Regarding the lock file, I assume that its deletion by Access is the last action performed once a database is closed, which would make sense since it’s the whole purpose of a lock file.
I do not attempt to delete the lock file, Access does that; the last sentence of the batch file, the DEL %0 actually deletes the batch file itself to keep things clean.

Thank you again for dropping by.

A couple of months back I tackled the issue of forcing a restart by calling a VB6 EXE on an Access UNLOAD event and passing the database file path as a command-line parameter. Now I can see your self-contained BAT file approach is better. I used WAIT to delay the restart, and then trapped the Unable to Unlock File error in a resume loop until Access unlocked the MDB file and deleted the LDB file. I was wondering why in your code, you try deleting the LDB file outside Access? Is there not a risk of corruption as the previous instance of Access would still exist until after its deletion of the LDB file?