Identifying who has a record locked on Windows network
GCC Consulting
gccconsulting at comcast.net
Wed Jul 25 09:46:21 PDT 2007
> -----Original Message-----
> From:
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial
> .com
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
> elestial.com] On Behalf Of Don Coleman
> Sent: Wednesday, July 25, 2007 10:04 AM
> To: filepro-list at lists.celestial.com
> Subject: Identifying who has a record locked on Windows network
>
> List:
>
> I probably already know the answer to this but I'll ask anyway.
> On a Windows network (WIN2000 Advanced Server, Windows 2000 &
> WINXP Pro.
> Clients, fP v5.0.13 64 user license), is there anyway, within
> the Windows tools or using an external utility, to identify
> which user or work station (I'd take either) has a particular
> fP record locked in a file?
>
> Most nights, when my client is finishing their last few
> delivery sheets (packing slips) there is typically 1-2
> facilities that they cannot process/print due to a locked
> record. Since time is of the essence at this time of the
> evening (FEDEX waits for no one) the supervisors don't have
> time to walk around a large multi-floor building and check
> who may be sitting in the update mode on a record for that
> customer. The customer (1 is
> complaining) is tired of having their delivery sheet faxed to
> them the next day. They just want it included in their
> order. They can always print it the next day because whoever
> had the file locked was knocked off at midnight when the
> network share is disabled for maintenance.
>
There is a way to see who is still accessing fileopo from the server.
This may not indicate who is locking the particular record. See below:
This is a screen shot from my server and shows the files I have open.
If someone is shown to have an open file such as the second to last item
listed, and they are not supposed to be on the system, you have several
options, if they are still working, contract them and advise them to get out
of the system, have someone go to their desk and manually exit them from the
system or lastly but not the best way, end the session by right clicking
and select "close open file".
I ran a test on this option:
Opened Word and loaded a letter from the server. That file showed as an
open file. Right clicked and took the option to clode the file. The file
was closed on the server but remained in my workstations memory. When I
exited Word, it asked me if I wanted to save the file. I did and the small
modification I made was still there when reopened.
Won't guarentee what will happen with a filepro file as I haven't test
closing a key in this manner.
You also have the option of loggin someone off from the sessions folder. I
have has to use this option a few time from terminal server when a user has
timed out and not logged off, leaving there session connected and I needed
to modify a file structure.
My suggestion is to use a test file and test closing the file when viewing a
record, when in update mode on a record and when adding a new record to se
the how the file is affected.
Richard Kreiss
GCC Consulting
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.celestial.com/pipermail/filepro-list/attachments/20070725/aef30f6d/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 16310 bytes
Desc: not available
Url : http://mailman.celestial.com/pipermail/filepro-list/attachments/20070725/aef30f6d/attachment-0001.gif
More information about the Filepro-list
mailing list