I've run into particular problem developing a Paradox-based program. The
first time I executed one of its options, which have finished successfully,
but the second time I have tried it, I get this following result: "invalid
parameter" in the middle of the execution, the third time I have tried to
execute it, I get "lock file has grown too large" inmediatelly.
If I close the entire program and I re-execute it, I find it as it was
before, the first time it works, the second time i get "invalid parameter"
and in the third time I get "lock file has grown too large".

The problem is not the numbers of executions. It's the numbers of iterations
of the algorithm. If I fake the program in order to make more iterations,
the first time it crashes ("invalid parameter"), and the second time I get
"lock file has grown too large"

This algorithm always reads unnumerabled times over 30 tables and there are
so many wrinting and deleting in only one of them (table).

Does anyone know about this problem? How could I avoid the "lock file has
grown too large"?

hth,
Dan

The answer was here:

TI256B.txt   Removing "Lock file has grown too large" Error
Category   :General Programming
Platform    :All
Product    :BDE  All

Description:
Lock file has grown too large, Decimal:9495 Hex:2517
----------------------------------------------------
This problem is specific to Paradox tables and can be caused
in any BDE (16 or 32 Bit) application that meet some or all
of the following criteria:

  1)  The Executable is in the same directory as the table.
  2)  The Private Directory is not correctly set or not set
      at all.
  3a) Delphi: Having a TTable open on a paradox table and
      then performing multiple TQuery operations.
  3b) C / C++: Having a table open with DbiOpenTable and
      then performing multiple queries with DbiQExec and/or
      DbiQExecDirect.
  4)  LOCAL SHARE set to true in the BDE Configuration
      Utility on the System page.

To solve the problem, make sure that your application has
done ALL of the following:

  1)  Under the directory where the executable is, create
      three new directories: TABLES, PRIV, and NET.  Place
      all the tables for the application into the TABLES
      directory.
  2)  Set the session's private directory to the PRIV
      directory.  Take the following steps according to
      the software you are using.

      DELPHI:
      Session.PrivateDir := ExtractFilePath(ParamStr(0)) + 'PRIV';

      C / C++:
      DbiSetPrivateDir(szPath);
      // szPath is the fully qualified path (not relative)
      // to the PRIV directory.

  3)  Set the session's network directory to the NET
      directory.  Take the following steps according to
      the software you are using.

      DELPHI:
      Session.NetFileDir := ExtractFilePath(ParamStr(0)) + 'NET';

      C / C++:
      DbiSetProp(hSes, sesNETFILE, (UINT32)szPath);
      // szPath is the fully qualified path (not relative)
      // to the NET directory.

      // hSes is the current session handle.  This can be
      // retrieved using the DBiGetCurrSession function.

  4)  If LOCAL SHARE is set to true and you are not sharing
      tables between different applications at the same time,
      change LOCAL SHARE to false.

A couple of times I have reported it being wrong in here
comp.lang.Pascal.delphi.databases, too. Also TeamB members have
admitted it being wrong.

Yet that erroneous advice still hangs on Borland's FAQ archive.

Everyone can see, that if you follow that tip, both the NetfileDir
and PrivDir will be set to point to your local hard disk.

And that is absolutely wrong with multi user installations. The
NetFileDir should be pointing to a shared directory on the server.
Otherwise record lockings won't work, and you'll get corrupted
data and indexes in minutes.

If you had your application EXE-file residing on the server's hard
disk, then the above setting would make NetFileDir to point to a
right place. But then Priv Directory would be wrong. And that
would cause the Queries starting to behave very strange, and giving
false results.