Shut down BDE from code

Question

We have a legacy application uses the BDE. (The BDEcontinues to work surprisingly well, given its age).

There are times when our app needs to manipulate folders (Rename, move, etc.) but a .NET or .LCK file remains open in the folder, preventing that. We have been unable to find any table or query still open in our code.

Other than having our program shell to a non-BDE program and itself terminating, is there a programatic way for us to shut down the BDE, which would unlock these files.

Standard disclaimers : Yes, the BDE is dead. Yes, we should migrate to a more modern database. Yes, someday the BDE just won't work anymore. With almost 2 million lines of legacy code, migrating (even with a somewhat plug compatible platform like Sybase Advantage) isn't an inexpensive project, which is why we haven't done it yet...

Francesca · Accepted Answer · 2012-04-20T18:57:11.743

2

You normally don't have anything specific to do for shutting down the BDE.
All the BDE Sessions are freed in the Finalization section of DBTables. This will close everything and when the Default Session is destroyed as well it will call DbiDLLExit if needed, then DbiExit, both from the BDE unit.

Now, if you want to shutdown the BDE before, I suggest you do mimic the finalization then initialization parts of DBTables (disclaimer: limited testing, use carefully...) like:

procedure BDEKill;
begin
// from finalization
  Sessions.Free;
  Sessions := nil;
end;

procedure BDEReStart;
begin
// from initialization
  Sessions := TSessionList.Create;
  Session := TSession.Create(nil);
  Session.SessionName := 'Default'; { Do not localize }
end;

and use it like:

BDEKill;
try
  // move my folders
finally
  BDEReStart;
end;

edited Apr 20 '12 at 18:57

answered Apr 19 '12 at 17:55

Francesca

21,452
4
49
90

Although not all the items in your sample code (and finalization code) were visible in the DBTables interface, the Sessions variable was. Using just that variable I was able to unlock the files in question. Thanks, François! – RobertFrank Apr 19 '12 at 21:22
+1: @François now that the code has been tested, don't you think the post need to be brushed up? – menjaraz Apr 20 '12 at 05:07
@menjaraz, code cleaned! (Even fired BDEAdmin to test it; 1st time in years!) – Francesca Apr 20 '12 at 18:59

menjaraz · Answer 2 · 2012-04-20T05:09:14.593

1

Unlocking file is another possible (extreme) solution to your issue:

I suggest you to study the source code of File Unlock by opc0de.

Quote:

All too often a file cannot be deleted because it is in use by another application. This tool allows you to unlock that file for deletion.

Look and feel:

File Unlock by opc0de

Features:

Unlock file
Unlock & Delete file
View which processes use the file
Terminate the processes which uses the file

Download link:

FileUnlock.rar

edited Apr 20 '12 at 05:09

answered Apr 19 '12 at 19:13

menjaraz

7,551
4
41
81

Sorry, I've already deleted my comments... This discussion led to a not related topic. My opinion is that I would prefer to use this if the BDE natural form (posted by François) wouldn't work ;-) – TLama Apr 19 '12 at 20:40
1

@TLama: You are right. The cleanest and elegant way to solve a BDE problem is to use every possibility provided by BDE itself. Unlocking file is a last resort solution although it works and even recommendend in some extreme cases. Thank you for your insights. – menjaraz Apr 20 '12 at 04:59

Shut down BDE from code

2 Answers2