Paradox Lock File Problem 2

[jracle]

I am running both Paradox 5 & 9 on a Novell 4.1.1 network. Problem is, when one uses access the data file which is stored on the network, it prevents others from accessing it at all. I know the locks are to prevent simultaneous editing of the data base but users should still be able to view the data file. This does not occurr one all machines, just most. The desktop machines are running WIN '98, 2K, and XPPRO.

This problem just surfaced recently and we are unable to identify any change that might have caused this.

Any help would be appreciated.

 

[footpad]

jracle,

Hm, sounds like that one of your users doesn't have their private directory defined and that your database directory is the default directory they're using when they fire up the program. When this happens, Paradox typically assigns the working directory as the user's private directory, which in turn locks other users out.

For each user, verify that their private directory is set to something on their C:\drive, such as their %temp% directory.

You can also do this by modifying the shortcuts used to start Paradox by adding the -p switch to the command that starts Paradox. (Please see

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

for more information.)

Hope this helps...

-- Lance

 

[jracle]

Thanks, I will have to take a look at each user. I never thought to look at the temp directory.

Jim

 

[jracle]

Thanks for your response. I changed the starting directory to the PRIVATE directory. This, at least, allowed me to open the program as I was getting the Unable to Initialze BDE error before.

I still can't open the data file as I get the following error message: Multiple.NET files in use.
FILE I:\DATA\LABLES\PDOXUSRS.LCK

Is there another change that I need to make.

I really appreciate your response and help.

Jim

 

[Kliot]

jracle,

You also need to be sure that all users are pointing to the same net file and that local share is set to true. You can check this in Paradox under "Preferences -> BDE" if they are not you must correct this with the BDEconfig utility. If they are and you still get the problem kick everyone out of Paradox and delete all the *.lck files on the working directory and in the users private directories. After that all should work fine.

Perrin

 

[footpad]

Jim,

Take a peek at

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

which documents the main causes for this. I have heard that certain versions of Novell's Client32 can also trigger this error, so if you're using their NOS, you may need to update Client32 as well.

Hope this helps...

-- Lance

 

[jracle]

I did have a problem with the client as I am running this particular copy of PARADOX on an XP PRO box. I had the Novell Client 4.83 and could not access the data file at all. I did download service pak 2 and was, at least, able to get the program to run.

I did as Kliot recommended also but I knew that the path to the .lck file was common to all machines. At this point, it is still a mystery. I can get to the data file provided that nobody else is logged on to it. Once someone opens the file, I am locked out.

Jim

 

[B4K9]

You might try doing a search on one of the problem machines, for "*.net", sometimes if you have a problem and get bounced out of the older Paradox progams, it will dump a Pdoxuser.net file anywhere,but usually in the C:\temp directory. If there are any, delete them, I have to do this every now and then, this can also cause win98 to hang at the "Windows is now shtuing down" screen.

 

[ExCorel]

Hi,

Sorry for the delay, just found this site.
With the combination of Pdox 5 & 9 * Novell, there are four things to be aware of (as Lance mentioned), namely

1. Update client 32
2. Set local share to True in the BDE
3. Opportunistic locking
4. Correct Net Dir alias

But users must also shut down Paradox correctly i.e. not just switch their machines off.

Opportunistic locking is a feature in Windows that is enabled by default, and will cause problems in a database environment - it's best to leave locking to Paradox and the BDE, so you might want to disable it.

The feature is located in Control Panel | System | Performance | File System | Troubleshooting, then place a checkmark in ‘Disable new file sharing and locking semantics'. While you're in there, you might also ‘Disable write behind caching for all drives' - this can cause corruption in indexes\tables,"index out of date" messages etc. Opportunistic locking basically means that NT writes to disk when ever it has some spare time. In a multi user database this just doesn't work.

Darragh Quinn

 

[footpad]

Darragh,

Just as an FYI that you may not have run into (but I have), use care when upgrading Client32. Novell sometimes relelases updates that cause additional problems (3.02 comes to mind).

When updating any component, it's a good idea to keep copies of the files that are replaced, just in case you need to roll the update back.

In addition to the Optimitic Locking issues, there are a few other tweaks that can be useful:

1. Many Novell settings are set to their minimal values for performance reasons. However, these values can create more traffic for Paradox applications. As an example, consider the Receive Buffer Packet Size, which (IIRC) is normally set to 1.5K. Since Paradox tables allocate table buffers in larger increments, the Novell default setting can increase traffic (requiring, for example, three packets to transmit one table block). Thus, it's a good idea to have the network admin carefully review all default settings and boost them to sizes useful for the applications.

I mention this because I once worked in an office where they needed 650 users to access a single Paradox application. Yes, the documented limit is three hundred. However, boosting the Receive Buffer Packet Size to its maximum value solved concurrency issues and allowed all the users to use the same application with no troubles whatsoever.

Granted, this is an extreme case, however, it shows the wisdom of knowing as much as possible about the data environment.

2. Many additional configuration tweaks and settings can be found at the BDE Support website. (See

http://bdesupport.com/stability.htm

and

http://bdesupport.com/perform.htm

for some terrible useful ones. While it's written from a Delphi perspective, the information is very useful for Paradox for Windows applications as well.

Hope this helps...

-- Lance

 

[DavidxH]

I have ran into a similar problem, Under 95,98,ME all was OK untill an XP tried to open the database. I could not, untill the non-XP users all loged out. If the XP started first then the ME could not logon.

95,98,ME use the " Pdoxusr.Lck " file.
XP uses the " Pdoxuse.net " file

If you clear out the Paradox.Lck, Proxusrs.Lck, Pdoxusrs.Net files you will only see first 2 files appear the first time 95,98,ME - Opens the database.
When XP Opens the database "Pdoxuse.net" will show up.

I had to set the BDE Administrator's - Options to Windows 3.1 and Windows 95/NT to get the error message to go away.
But I have NOT found out how to have ME and XP users in the database at the same time.
Hope this gets you closer to a solution.

 

[nawtykitty]

One thing I have found when you add a WinNT-based (WinNT 4, Win2K, WinXP, Win2K3) Workstation/ Server into your mix of systems on a network, you have to disable Opportunistic File Locking. NT-Based systems have a real tendacy to hold onto network data and prevent multiple users from at least viewing the same data. Microsoft's reasoning is to help prevent data corruption within the same data that is being called by the multiple users. Older database or non-Microsoft software products should really be left alone by the operating system. They like to dish out and share the data their own way. So I think that opportunistic file locking should be disbled right off the bat. I really believe that this will move you closer to solving your problem because it seems that you did not have this issue until you added a WinNT-based system onto your network. Do a search for Microsoft Knowledge Base Article 296264. This will walk you through disabling opportunistic file locking on your WinNT system.

Personal Experience With This Issue:

TeleMagic Version 3: Server hosting the application would freeze when more than five users would try to access the software program. Once opportunistic locking was turned off on all workstations and hosting server, all users could access the database at once. Telemagic had a Foxpro backbone. Also, the Telemagic Software was previously hosted on a Novell 3.11 Server before being migrated to a WinNT 4 Server. Problem did not show up until after Data Migration.

Syspro 6.0: Server would lock up after about a couple of hours of all users accessing various aspects of the software. The host server was a WinNT 4 server to begin with. Then upgraded to a Win2K server to resolve the locking issue at the insistance of reseller. Reseller had denied that Opportunistic File Locking was not the reason for the lockup. The fact that WinNT 4 was the host server OS was the reason for it. Still had the same problem after upgrade until after opportunistic file locking was disabled.


I hope all of this info helps. I know it is long-winded, but I hope it shows that sometimes a software package just needs to be left alone by the OS.