Eliminate File (.lck) lock problems on a network

[sloinc]

Have been implementing a multiuser application on windows 2000 server. Keep running into problem with trying to open a form and locking the system. I believe the problem is the table attached to the form is in use by another.

My question-

Where would be a good place test and how to find out if the table can be openned. Next if the table can be openned, were and how to place a lock. Next, if any of these tests fail to post a message.

I have used the examples in Paradox help with some success.

I don't get setretryperiod()

Thanks in advance for any help.

 

[footpad]

sloinc,

While it's possible to fully control the locking process, I've found that most problems are caused by configuration errors, rather than weaknesses in the default locking that Paradox.

In general, you need to make certain of the following things when setting Paradox (and BDE) up on a network:

1. Each user has a unique private directory that they have complete rights to.

2. Each user needs to have access to the network control file directory and each copy of BDE needs to be using that directory for the PDOXUSRS.NET file. (See

http://techtricks.com/paradox/netinit.php

and

http://www.thedbcommunity.com/faq/13.htm

for more information.) Everyone needs full and complete read/write access to this directory.

3. Make certain that all drives are actually mapped to each machine; do not use UNC paths.

Once all that is set up, then things go pretty smoothly. Paradox uses a pessimistic locking mechanism, which means that it automatically prevents other users from locking a record that someone else is editing. Except in pretty extreme cases, this is hard to improve on.

As far as the retry period goes, that's the amount of time that Paradox waits before trying to gain a lock after that lock has failed. An exceptable value depends on the network and the application. I'd start with 20 seconds and see how it goes.

If that seems way too long (and it might), then knock it does, but be prepared for more frequent locking failures.

Hope this helps...

-- Lance

Hope this helps...

-- Lance