"lock file has grown too large" 
Author Message
 "lock file has grown too large"

Sorry if this message has been already posted. Servers problems.
---

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"?

Thanks.



Wed, 08 Oct 2003 04:19:23 GMT  
 "lock file has grown too large"
If I remember correctly, this problem comes from having the NETDIR the
same as the DATADIR. In other words, if pdoxusrs.net is in the same
directory as the .db files. Try putting it in its own dirictory, such
as c:\net. DON'T put it in any root dir; that causes other problems.
Some put it in the .exe dir, but personally, I prefer to have a
separate dir just for the netfile. (makes it easier to find and delete
if there is a crash ;-)

hth,
Dan



Quote:
>Sorry if this message has been already posted. Servers problems.
>---

>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"?

>Thanks.

--
Dan Brennand
CMDC systems, inc.
Configuration Management and Document Control:
visit us at www.cmdcsystems.com



Wed, 08 Oct 2003 07:32:30 GMT  
 "lock file has grown too large"

Quote:
> 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"?

Perhaps the information here will help:
http://bdesupport.com/errors.htm#lockfilelarge

--
Vinnie Murdico
The BDE Support Page
http://www.bdesupport.com



Wed, 08 Oct 2003 12:11:02 GMT  
 "lock file has grown too large"
The problem is with NETDIR but try using cached updates


Fri, 10 Oct 2003 14:28:52 GMT  
 "lock file has grown too large"
Thank you very much.

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.

The above steps will correct the Lock File Too Large error.



Wed, 15 Oct 2003 04:58:54 GMT  
 "lock file has grown too large"

Quote:

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

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

I have reported to Borland, that this Paradox setting advice is
wrong. And not once, but about 5-6 different times on years
1998-2000 on Borland's borland.public.delphi.database.desktop newsgroup.

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.

Markku Nevalainen



Thu, 16 Oct 2003 08:04:08 GMT  
 "lock file has grown too large"


Quote:

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

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

> 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.

And to cap it off, if one has multiple sessions using the same private
directory is sure to lead to problems.


Sat, 18 Oct 2003 10:54:05 GMT  
 
 [ 7 post ] 

 Relevant Pages 

1. "Lock file grown too large"

2. HELP!!: "Multiple net files","Lock file has grown too large"

3. "Lock file has gorwn to large"

4. URGENT - Lock file grown too large - error using Paradox files

5. Help: "Help file to large"

6. "File is Locked" error message

7. The keys "-"/"+"/"*"

8. Lock file has grown too large

9. The lock file has grown too large?

10. Lock file has grown too large - please help

11. 'Lock file grown too large'

12. Lock file has grown too large??

 

 
Powered by phpBB® Forum Software