Record is being update-Access denied message

[Don G. Coleman]

---------- Original Message ----------------------------------
From: Kenneth Brody <kenbrody at bestweb.net>
Date:  Sat, 26 Aug 2006 14:59:27 -0400

>Quoting Jay R. Ashworth (Fri, 25 Aug 2006 11:25:49 -0400):
>
>> On Fri, Aug 25, 2006 at 10:22:14AM -0500, Rick Mitchell wrote:
>> > From: "Don Coleman" <dcoleman at dgcreact.com>
>> > > Windows 2000 Advanced Server, WINXP & WIN2000 clients, fP v5.0.13
>> > >
>> > > My client has found one record in a file which messages "record is
>> > > being updated-access denied". Last night they rebooted their server
>> > > and they are still getting the message today. While it is possible
>> > > someone is back updating this record I would find it unlikely. Do I
>> > > have any other options for gaining access to this record?
>> >
>> > kill the lockfile.
>>
>> Well, in my experience, that message doesn't *come* from the lockfile;
>
>You are correct.  As I have stated repeatedly on this list whenever
>someone mentions "remove the lockfile" for clearing record locks...
>
>    The lockfile has absolutely nothing to do with record locks.
>    Nothing.  Nada.  Zip.  Zilch.
>
>The lockfile is for inter-module locking -- something which record
>locks cannot do.  For example, prevent someone from building a new
>automatic index when someone is in *clerk in the file.
>
>> record level locks are maintained in the kernel lock table, and
>> usually, a reboot should clear up the problem.
>
>If a serverreboot doesn't clear the locks, something is very wrong.
>
>> Is it possible they have an overnight cronjob that runs something and
>> has gotten stuck on a record?
>>
>> Run (or get and run) showlock, and see what it says.
>
>As someone else pointed out, this is Windows, and even sysinternals.com
>doesn't have any showlock-like utility that I can see.
>
>However, that doesn't mean that another workstation can't have locked
>the record since the reboot.
>
>--
>KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
>http://www.hvcomputer.com
>http://www.fileProPlus.com
>_______________________________________________
>Filepro-list mailing list
>Filepro-list at lists.celestial.com
>http://mailman.celestial.com/mailman/listinfo/filepro-list
>

The client was able to resolve this issue by doing a reboot a second time Friday night and accessing the record before any of the clients were rebooted.
When they attempted this Thursday night they had not shut down each client but tell me they did ensure each client was either out of the fP application completely or sitting on an fP menu.  So the difference was shutting the client down and not restarting until the problem was resolved.  Regarding this network, we have been having DKNY problems for the past several weeks on an index that has not been modified for approximately 18 months.  The fP app. that writes this index has also not been modified in that time frame.  Now, most days we have to have everyone exit fP and rebuild this index once per day.  We have noticed that when we have everyone "supposedly" shutdown their client (not just exit fP) we will still see 20-40 users with files open on the fP share.  We have begun to disable the share before performing our index rebuild.  fP is installed on the server (Windows 2000 Advanced Server) and p.exe is run on the client from the mapped drive to the server.  I am beginning to think the clients (WINXP PRO & WIN2000 clients plus two WIN98SE clients) are the problem (broken) and wonder if accessing fP via Terminal Services or Citrix on the server would help.
Any thoughts?

Don Coleman   




________________________________________________________________
Sent via the WebMail system at mail.dgcreact.com