lck files not deleting from private directory

[JBirdieH]

Since the upgrade to PDOX10 the .lck files regularly are not deleted from the private directory upon exit. Of course that creates problems for the next attempt. Is there an additional step that should have happened during configuration of the clients or server to avoid this? Nothing else has changed on the network, and this was not a problem in PDOX9. Thanks.

 

[footpad]

JBirdieH,

I've seen a few different cases where that can happen:

1. Installation can reset your private directory; verify that Paradox 10 thinks your private directory is where you think it is. (One of the tip offs for this is that you're getting .LCK files, something that shouldn't happen in your private directory.)

2. You're using a utility or other BDE-enabled program (typically written in Delphi or C++ Builder) that is using a different private directory (which makes sense, as each application is considered a separate user). This means re-organizing things a bit.

3. TCursors are going out of scope without formally being closed. This doesn't happen as frequently as it used to, but there are scenarios when it's possible it could happen. If you're using TCursors, be sure to formally close them before they go out of scope, e.g:

if tc.isAssigned() then
   tc.close()
endIf

Mind you, I'm not saying these are the actual causes of the problem, but they are causes I've seen. There may be others.

Hope this helps...

-- Lance

 

[ACCESSDUMMY]

Lance,
I'm having a similar problem with a Paradox application that is being used via a Citrix server. In addition to the Paradox .lck files being in the private directories of the users, there are also .out files and some weird looking .db files. They typically look like this: _QB7345.db

Have you ever seen this or know what is causing this to happen?

Thanks in advance,
Amy

 

[TonyMcGuire]

From Bertil's Buglist:

Printing a report with more than one table in the datamodel, when the report contains a group band, and when interactive printing will cause the infamous warning, "Report layout setting have been changed...", will leave a lock on the detail tables in the datamodel. Tables cannot be renamed or deleted.

The problem occurs under the following condition:

The report is based on a data model has three temporary tables linked 1-1 and 1-M. For example:

RIVrime.db -------> -RIV:OneToOne.db
|
|-------------------->> RIV:OneToMany.db

Use unbound fields in the record band (no tableframes). Add a group record band based on any Field in the OneToOne.db. (Adding the group band seems to trigger the behavior described below. Without the group band, the table lock is released.)

Behavior: Print the report and close it. Try to delete the temporary tables. Paradox will let you delete Prime.db and OneToOne.db. But if you try to delete the OneToMany.db, the operation will be denied with a "Table In Use" message. The only way I've found to unlock the table is to exit Paradox altogether and delete lock files in PRIV dir. Bad news.

Read all about it: Further down he addresses the .out files.

http://web.comhem.se/~u82608896/paradox/openbugs.htm#PX0506

Tony McGuire

http://www.thedbcommunity.com

"It's not about having enough time. It's about priorities.

 

[ACCESSDUMMY]

Well Tony... I do have a very complicated data model for one of the reports. It looks something like this:

table1 -------->> table2 (one to many)
| |
| |---> table3 (one to one)
|
|--> table4 -----> table5 (one to one)
(one to one)

On top of that, I do have a couple of group bands as well as a table frame. I'm kind of at a loss as to where to even begin to start changing this report. One of the reasons it's so complex now is because previously I had filters on the report. Recently we learned that Paradox filters seemed to cause problems with our programs on Citrix.

Thanks for your reply! I guess it's back to the drawing board on this one.

Thanks,
Amy