Browse DevX
Sign up for e-mail newsletters from DevX

Tip of the Day
Language: Pascal
Expertise: Beginner
Mar 28, 1997



Building the Right Environment to Support AI, Machine Learning and Deep Learning

Resetting Net and Lock Files

Is there a way to reset the net and lock files that an application develops without having to shut down the software? Even a temporary pause would be acceptable.

We develop professional software in Delphi. We have come across a problem that Borland cannot help us with. It goes like this:

  • The application with the problem is medical practice management software.
  • The problem site has this application on five computers linked to a single server/workstation, all using WFW 3.11.
  • Each machine opens 43 tables upon start.
  • SQL usage of each machine is fairly high.
  • BDE is set to maxfile handles of 48 (standard settings).
  • At approximately the same time each day, the server machine gives the exception: "Lock files has grown too large."
  • Borland says problem cannot be stopped.
  • Borland says to add "cleanup" files to delete lock and net files upon boot. We have done this.
  • We cannot afford to have whole system and users stop while the software is shut down and the system restarted daily.
  • Borland has been no help. They know what fixes the problem, but the solution required obstructs our clients too much.

I'm very familiar with this problem, because I've run across it a few times. There are a number of things that can cause the error, and would you believe it, they didn't fix it in the 32-bit version of the BDE either? Here's a list of the problems that I've found cause the error. Borland knows about this, by the way, so the tech that told you how to fix it was way off base. Here are the problems:

The most common problem is running several queries on already open tables or several open tables. It looks like this is your problem from what I can gather from your message. What is happening in this case is that the lock file keeps track of changes occurring on the table. When you have an open cursor on a table, then do queries, the BDE enters records in the lock file to help keep track of the accesses. It doesn't reset them because the owner (you) is the same for both the table cursor and the queries. In other words, it can't tell the difference between what's completed and what is not. It just sees that you've got several open resources. Kinda dumb, huh?

But this brings the question of your application design. You said you're opening 43 tables at runtime. In my experience with the BDE (back to Paradox days, which covers about 11 years), that's a big fat no-no. I don't doubt that your program is quite nifty, but consider this: a single table takes up a lot of resources, especially if there are a lot of records in it. Add a datasource and data controls to the picture, and you've got a real resource problem. Furthermore, if you've got all your forms in autocreate, remove all the ones that aren't absolutely necessary at runtime from your autocreate list in your project options. Forms take up heap and stack space that are precious commodities. A rule of thumb that you should consider is this:

Only open a form or table when absolutely necessary. Then when you're finished with it, destroy it to free the resource space.
You'll do yourself a big favor -- especially with large applications -- by heeding this advice.

I discovered this problem on my own and got confirmation from a BI engineer after a lot of prodding. My situation was that I was doing several queries on the same dataset over and over again. The table was pretty big — about 225 MB and more than a million records. After about an hour, my lock file would grow to 20 MB! Not good.

Here's some more problems that will cause the error to occur:

  • If you've got LOCAL SHARE set to true in the BDE configuration utility (IDAPI), change it to false. LOCAL SHARE means stand-alone, which your application is not. The BDE will not recognize resource locking changes in this case; thus, the lock file will grow.

  • The Private Directory points to a non-existent directory, to the same directory as the application, or is not set at all.

  • Your EXE resides in the same directory as the table. For some reason, the BDE doesn't like this co-existence of data with an executable. If you have your application in the same directory as your tables, move it, and use an alias or relative directory addressing below your application directory to access your tables.

In closing, let me give you another piece advice (oh no! ). When you call Borland, if you get a weird answer like you got before, don't believe it. Usually those types of answers come from a newbie technician who doesn't have much experience. If you feel like you're getting a run-around, by all means, ask (er.. demand) to speak with an engineer that's higher up the food chain. Don't be afraid to be a jerk with these guys because after all, you're one of the reasons their job exists in the first place. I know, it sounds rather jaded, but given Borland's track record for fielding problems, I've learned the ins and outs of the process.
DevX Pro
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date