> >I've been having a problem with a particular VFP3 application running > >under Windows 3.1, with the application on the local drive and the data > >on a Novell 3.x server. > > > >The problem is that sometimes the application won't see an RLOCK() be > >released. I use this as a semaphore on the users table, to indicate > >that a particular user has logged in. The user has exited FoxPro, > >exited Windows, and has even shut down the PC. Yet the RLOCK() still > >remains. This is indicated because the user cannot log into the > >application on a different PC (they keep getting an error indicating > >that they are already logged in). We checked the Novell CONSOLE screen, > >and the second PC is the only one that has the file open, yet it still > >can't establish a lock. > > Paul, I've seen it in other programs, usually because the user exited the > program without closing all tables. It's always been on a Novell 3.x > server. The System Administrator said that Novell puts its own locks on > files when xBase does, and doesn't always release them. My only recourse > was to ask the SysAdmin to set the Novell to release a lock on any file IT > has locked if the file is not in use by a program. This way we only had to > wait 10 minutes. It turned out to be a simple matter at the Novell level. I had assumed that the WatchDog packet would have released all of the locks for a connection when it released the connection itself. I'll look into this. Thanks.