"lock file has grown too large"
Author |
Message |
sna #1 / 7
|
 "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 |
|
 |
Dan Brenna #2 / 7
|
 "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 |
|
 |
Vinnie Murdic #3 / 7
|
 "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 |
|
 |
prka #4 / 7
|
 "lock file has grown too large"
The problem is with NETDIR but try using cached updates
|
Fri, 10 Oct 2003 14:28:52 GMT |
|
 |
sna #5 / 7
|
 "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 |
|
 |
Markku Nevalaine #6 / 7
|
 "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 |
|
 |
Bruce Robert #7 / 7
|
 "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 |
|
|
|