In fact, your 3rd paragraph sounds exactly like what we experience when 6 nightly deletes doesn't happen. The network detective's comment should be investigated. Is the anti-virus software slowing file access? Is it a problem with using UNC rather than mapped drives? Have you adjusted these we have a few machines that insist on "auto" or "hardware select" whereas others like Mb Full duplex forced Nevermind, this one deleted as it was irrelevant.
Check the delete rights - some clever server admin type may have decided to take away the delete rights that was killing us for a while cuz the lck files weren't deleted - didn't show up as a problem until user count increased beyond a magic number. You moved PRIVs from a different server and the problem hasn't recurred.
That should be a hint. Look at the other server and the connection thereto. NET and. LCK files can get corrupted. Netware 3. Never found a solution because we eventually migrated. New position listings on www. I've been on-site with clients and had the same "sharing violation" on local and shared files.. The only interaction between these and Paradox is that if sometiimes if Paradox gets hung up and is terminated then GW goes away too.
Restarting either, restarts both. Sometimes a Paradox session getting hung up has no effect on other Citrix apps, sometimes it locks upp the entire citrix session and everything in it. I was trying to describe the behavior that we I see. Clear, clear, clear how ever many seem to be queued up or what ever it is and then everything seems to be back to normal. The size of the queue the apparent one based on what it looks like can be some users or all of them.
As I understand the pdoxusrs. Every folder where there is data being accessed has its own pdoxusrs. Every user must apparently have the pdoxusrs. When a user needs to write to the pdoxusrs. If any user has the pdoxusrs. You get an access denied, file in use message absolutely correct.. So far max users on any one Citrix Box load balanced between 3 when two were running was No differece between the load when it is working and not.
Actually when it is working, the load goes up, everyone is trying to catch up. It looks like the. They all have a create date on today. I have a 1hr maint period each night when. What actions cause the. The inventory table 6K records probably has , changes per day most of which include an explicit record lock and unlock. I've seen reports of 3 meg lock files.. This company is growing and will should and is planning on outgrowing this in 3 yrs.
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. Red Flag This Post Please let us know here why this post is inappropriate. Reasons such as off-topic, duplicates, flames, illegal, vulgar, or students posting their homework. The Tek-Tips staff will check this out and take appropriate action. Click Here to join Tek-Tips and talk with other members!
Already a Member? Join your peers on the Internet's largest technical computer professional community. It's easy to join and it's free. Register now while it's still free! Already a member? Close this window and log in. Join Us Close. Join Tek-Tips Forums! Join Us! By joining you are opting in to receive e-mail. Promoting, selling, recruiting, coursework and thesis posting is forbidden. Students Click Here.
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. This problem just surfaced recently and we are unable to identify any change that might have caused this. Any help would be appreciated. When this happens, Paradox typically assigns the working directory as the user's private directory, which in turn locks other users out.
You can also do this by modifying the shortcuts used to start Paradox by adding the -p switch to the command that starts Paradox. Thanks, I will have to take a look at each user. I never thought to look at the temp directory. Thanks for your response.
I still can't open the data file as I get the following error message: Multiple. NET files in use. LCK Is there another change that I need to make.
I really appreciate your response and help. Once the database is open, a read access does not require any lock, therefore users do not need to write to the lock file, therefore the pdoxusrs. When a user program accesses a table in "update" mode, it locks the record for writes.
The write lock is exclusive. As soon as a table is opened in update mode, the lock file is created automatically in the table location. If the lock file exists, it is temporarily locked for exclusive write and a lock record is written to it. When the last user program releases the update lock, the lock file is automatically deleted.
This again requires a temporary exclusive lock on the lock file. If you have no users on the system but the lock file is still there, this is an indication of some trouble having occurred. Otherwise, if neither read-only nor update modes are specified, the table is opened in an undefined mode and the user needs to write a table-wide non-exclusive lock into the lock file.
In order to place an exclusive lock on a record, the user program first needs to obtain an exclusive lock on the lock file. Subsequent user programs attempting to access the lock file for updates will fail and retry. The timeout parameter specifies how long the attempts should wait until an error is raised and the operation aborted.
It happens sometimes that a user kills the program because it appears to be frozen. At that stage, the lock file is not updated therefore the. All user programs get a BDE contention status and none is able to continue.
The only solution is for the lock file to be fixed or deleted. The user who actually "lost" the exclusive lock has to restart the system and log on again to the network. This will release the lock placed by this user, at least in a Paradox on Novell environment. Manual intervention is possible when it is clear that all application programs and interactive users are off the system.
You simply delete the lock file pdoxusrs. If you do that while any application or user is interacting with the data tables, it is a recipe for disaster even though the delete operation may not complete file is locked. It is tempting to speculate a while on the motivations behind these "restrictions" on redistributing the BDE. However, the customers may also be directed to the borland site to download the newest version — which basically means the installation program will simply check for the existence of a "core" BDE which it will upgrade regardless of the "license".
With version 4. Problems in using Paradox tables residing on NT Server when the applications access the data starting from Windows95 workstations are said to be related to the network redirector.
0コメント