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

We develop professional software in Delphi. We have come acrossa 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.

Answer:
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 believeit, they didn’t fix it in the 32-bit version of the BDE either? Here’s alist of the problems that I’ve found cause the error. Borland knows aboutthis, by the way, so the tech that told you how to fix it was way off base. Hereare the problems:

The most common problem is running several queries on already open tablesor several open tables. It looks like this is your problem from what I cangather from your message. What is happening in thiscase 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 entersrecords in the lock file to help keep track of the accesses. It doesn’treset them because the owner (you) is the same for both the table cursor andthe queries. In other words, it can’t tell the difference between what’scompleted and what is not. It just sees that you’ve got several openresources. Kinda dumb, huh?

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

Only open a form or table when absolutely necessary. Then when you’refinished with it, destroy it to free the resource space.

I discovered this problem on my own and got confirmation from a BI engineerafter a lot of prodding. My situation was that I was doing several querieson the same dataset over and over again. The table was pretty big ? about 225MB and more than a million records. After about an hour, my lock file would growto 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 yourapplication is not. The BDE will not recognize resource lockingchanges in this case; thus, the lock file will grow.

• The Private Directory points to a non-existent directory, to the samedirectory 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 anexecutable. If you have your application in the same directory as yourtables, move it, and use an alias or relative directory addressing belowyour application directory to access your tables.