Can't run reports because file locked?

[Kenneth Brody]

Quoting Dan Snyder (Thu, 8 Sep 2005 13:35:31 -0400):
[...]
> > Ken wrote
> > Rule #1:  Never remove the lockfile while the file is
> > in use, unless you like getting "help, our file is
> > corrupted!" calls in the middle of the night.
> I only removed the lockfiles, since showlock did not show anyone
> updating the files (and therefore I thought it would not risk
> corrupting the files).
> Additionally, in section 09.04.04 on Page 148 of Stuart Werner's
> filePro Plus Developers Reference says "It is perfectly safe to
> remove lockfiles."

I don't have a recent copy of Stuart's reference.  Perhaps there's
something in context that you missed?

Imagine someone in *clerk on a file, not updating any record.  You
remove the lockfile and create a new automatic index.  Anyone already
access that file will not see the new index, and will not update it
as records are created/updated/deleted.

Worse, imagine changing the definition of an existing auto index.

Worse still, imagine going into ddefine and changing a field length.

> > Rule #2:  Record locking and the lockfile have nothing to do with
> > each other.
> I figured that was the case since showlock didn't tell when someone
> was in the file, but removing the lockfile did allow reports to run.
> My issue is why did we just start getting this yesterday?

Perhaps you never attempted to run a report with output processing
while someone else was accessing the file in *clerk prior to
yesterday?

> > If you want to allow the report to run while others are
> > in *clerk, include the "-u" flag on the *report command
> > line.  That's what it's there for.
> I edited the dpromenu menu by adding "-u" to the menu option, I logged
> out, logged back-in and tried to run the report but it still gives the
> same error.

What is the exact command line now?  If you changed "/fp/dreport" to
"/fp/dreport -u", then you didn't add a "-u" flag, but rather added
a filename of "-u".  You need "/fp/dreport - -u".

> However, I now figured out that only reports with output processing
> are giving the error, even if the output processing doesn't have
> anything in it and therefore doesn't try to do any updates to the file.

Correct.  Reports simple enough to run with zero processing will be
allowed to run with someone in *clerk.

> Finding this I checked our other files again (like inventory) and they
> behave the same way.

Correct.

> I'm happy to have the problem more clearly identified, but I'm still
> concerned that this just became a problem yesterday.  I've interviewed
> all the users that access the file in question and the users that have
> run the reports that we are having problems with.  No one claims to be
> have changed their processes or filePro usage recently in a manner that
> would make this problem start happening all of the sudden yesterday.

Perhaps someone created an output processing that didn't exist before?
Perhaps they were "lucky", and never tried running the report while
someone else was in *clerk?  Perhaps it's something else entirely?

> Anyone have any other ideas why this issue just started happening or
> know anything we might try to get around it?

I can't tell you why it just started, beyond "something changed".  To
"get around it", use the "-u" flag if you want to allow the report to
be run while someone else is using the file.

[...]
> However, the company had it working that way without any problems
> for 10+ years before I got here.  I'm planning on replacing filePro
> with an off-the-shelf ERP package,

Why?  If they've been running it for 10+ years without any problems,
why switch?

> Besides, all our filePro files would need a complete redesign/
> recoding to fix their issues anyway, redoing the menus is the least
> of my worries.

What sort of issues?

--
KenBrody at BestWeb dot net        spamtrap: <g8ymh8uf001 at sneakemail.com>
http://www.hvcomputer.com
http://www.fileProPlus.com