Record locks survive after user has logged off

[Mike Lewis]

A client has reported a problem that I didn't think was possible.

This is an application written in VFP 6.0, running under Terminal Server, with around 60 simulataneous users.

Occasionally, a user will crash. When they do, it seems that any records they have locked remain locked, even after the user has rebooted their workstation. The only way to get rid of the locks, according to the client, is to reboot the server.

I find this difficult to understand. I can't see how a lock will survive the workstation crashing, much less rebooting. Have I got that wrong?

I think it's more likely that the records aren't really locked ... but I can't explain why it looks like they are.

If anyone can throw any light on this, I'd appreciate it.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[alvechurchdata]

Are they using plain old RLOCK() or have they written their own routine with a semaphore flag in the table?

Geoff Franklin

http://www.alvechurchdata.co.uk

 

[Mike Lewis]

Geoff,

They were originally using a combination of RLOCK() (and FLOCK()) and transaction processing. On my suggestion, they've removed most of the FLOCKs and RLOCKs, and are now relying on buffering and transactions.

As far as I know, they don't have semaphores.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[DSummZZZ]

I'm thinking it could be the instance of terminal server which would have the records locked rather than the user's workstation.
Maybe rather than rebooting the server, they could restart the terminal services 'service'.
Or, even use the API functions to clear connections. Take a look at the 'Open File Lister' utility on my web site. You may be able to use it - or a modified version - to clear those stale connections.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Mike Lewis]

Dave,

Two good-sounding suggestions. Thanks.

I'll get them to try restarting the service It won't be a long-term solution, but it will get them past the present difficulties.

I'll also take a look at your utility. I was going to suggest they used Filemon from System Internals, but it's nice to have a VFP-specific solution.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[baltman]

TS has a disconnected timeout setting. Have them set if to just a few minutes.

Longer term you can throw a timer somewhere to detect inactivity and release locks.

Brian

 

[Mike Lewis]

Brian,

Thanks for those suggestions. I don't know much about Terminal Server, but they have guys there that do, so I'll pass it on.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[Steve Bowman]

TS Clients can Logoff or Disconnect. This always causes me headaches because for me most TS users just hit the X in RDP Client instead of LogOff and in this will cause the TS "session" to remain "active" only "disconnected" and if your APP was running and locking a record when "client crashed" or "disconnected" you have the LOCK. All this can be seen from the Terminal Server. use Programs-Administrative Tools->Terminal Services manager from this application you can seel all "Active" and "Disconnected" Users and Processes running in the session. Do this when they are having the problem and I am sure you will see a "disconnected" session with you APP Process running. Instead of restarting the TS Service and kicking "everyone" out just right click the "disconnected" session and choose reset this will close and clean up this session freeing up the record lock. The suggestion of setting the disconnected session timeout to a low number is an execlent method to correct the issue. You will only have to have the customer understand the problem is TS based and not some flaw in your Aplication. I went around and around with a customer who felt it was the "application" at fault and kept telling me to "fix the application".

Steve Bowman
Independent Technology, Inc.
CA, USA

 

[Mike Lewis]

Steve,

This sounds like excellent advice.

I'm going to pass on your suggestions (and the others received in this thread) to the client. I don't know if it will solve the problem, but I'm sure it will take them a lot further forward. I'll let you know the results (although it might take a while, because the key person is about to leave for a holiday).

I'm especially pleased that you've confirmed it is a TS problem. I was worried that my understaning of VFP locking was fundamentally wrong.

Many thanks.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[DSummZZZ]

I was worried that my understaning of VFP locking was fundamentally wrong.

After all these years? You're daft man!

-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Mike Lewis]

Dave,

You're daft man!

That's why I was worried.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk

 

[StewartJ]

Thank you. I have had exactly this issue with a client today and have passed the suggested solution to their network support to implement.

 

[Mike Lewis]

Stewart,

I would be interested to hear the result. But, tell me, which particular suggested solution are you referring to?

My own client is still on his hols, so I haven't been able to take this any further, but I'll report back in due course.

Mike


__________________________________
Mike Lewis (Edinburgh, Scotland)

My Visual FoxPro site: www.ml-consult.co.uk