Lock File Too Large

[C.Ruybal]

Has anyone run into the BDE raising an exception "Lock file has grown
too large."

This is happening when I loop through one table, copying it record by
record into another. It is hard to reproduce, seems to happen
sporadically. I can run the routine repeatedly with no problems, and
at other times, right after rebooting, I will hit the error on the
first pass.

For all the tests I am using the same tables, so nothing is changing
there. I clear the destination table, and restore the source table
from a backup, so conditions should be identical for each run.

Any ideas?

Thanks

[BP]

Take a look at:
http://www.borland.com/devsupport/bde/ti_list/TI2993.html

C.Ruybal <chris....@ilg.com> wrote in article
<34e87a40...@forums.borland.com>...

[Bill Todd (TeamB)]

See TI2993 at www.borland.com/devsupport/bde/ti_list.

Bill

(Sorry but TeamB cannot answer support questions received via email.)
(To send me email for any other reason remove .nospam from my address.)

[clays...@hotmail.com]

In article <01bd3b08$b4f9f860$380a...@mrealm.ici.net>,

>This might help:

Lock file [has grown] too large

Possible Cause of Error
You may be using Paradox tables and one or more of the following scenarios
applies:
1. Multiple users are accessing the same Private Directory
2. The executable and the tables are in the same directory
3. The BDE Local Share setting is TRUE
4. You are executing multiple query operations against a TTable
Quick Fix
1. Set the Private Directory to a directory on each user’s hard disk (such as
C:\Temp). You could do that programmtically in this way:
var
Extension, ExecName, PrivDir : String;
ExtensionPos: Integer;
. . .
ExecName := ExtractFileName(Application.ExeName);
Extension := ExtractFileExt(Application.ExeName);
ExtensionPos := Pos(Extension, ExecName);
Delete(ExecName,ExtensionPos,4);
PrivDir := 'C:\Temp\' + ExecName;
if not DirectoryExists(PrivDir) then
CreateDir(PrivDir);
if DirectoryExists(PrivDir) then
Session.PrivateDir := PrivDir
else
raise Exception.Create('Private Directory ' +
' was not created!');
end;
2, 4. House the executable and the tables in separate directories.
3. If you do not have multiple executables simultaneously accessing the same
tables, set Local Share (in the System page of the BDE Configuration utility)
to FALSE. Leave it (or set it to) TRUE if machines on a peer-to-peer network
are accessing the table[s] via their own copy of the executable.
Additional Information
Note: Do not set the PrivateDir setting to a root directory on a drive; always
specify a subdirectory.
If your executable and tables share the same directory, the lock (.LCK) file
will increase in size every time a query is run.
You need to set Local Share to True if your tables are also being accessed by
non-BDE database engines, such as JET or ODBC.
If Local Share is set to False, no lock (.LCK) fiels at all are created.

Clay Shannon,
author of upcoming book "Troubleshooting Delphi - Quick Fixes"

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/ Now offering spam-free web-based newsreading

[Richard Luxenberg]

I have read and implemented the suggestions is the TI. However, my users were
experiencing data loss when Local Share was set to FALSE. Setting it to TRUE
(Borlands suggestion) stopped the data loss problems. Will this cause the Lock
File error still. The Borland TI suggests that ANY of the 4 items can cause the
problem.. Does this mean that fixing items 1, 2, and 4, but keeping Local Share
set to TRUE may not eliminate the Lock File too Large problem?? For data
integrity, I need Local Share to TRUE.

Thanks,
Rich
r...@tcdi.com

clays...@hotmail.com wrote:

[Scott Frolich [Borland]]

Hello,
Yes. Doing any one of the 4 will fix the problem.

Scott
--
BDE Support:
http://www.borland.com/devsupport/bde
Delphi Support:
http://www.borland.com/devsupport/delphi
Common Delphi and BDE Questions and Answers:
http://www.borland.com/devsupport/delphi/qanda/delphi3qa.html