>1. Test all data files, index and data contents for corruption. Then
>source code, too: SCX/VCX/FRX get corrupted sometimes.
All of this code is in .prg files once the user presses the "GO" button.
The production code has been fully recompiled and redistributed several
times in the last few months.
The ValidateTables() process that I posted opens tables under
SET("TABLEVALIDATE") = 3. And it runs when the user starts the application,
without error, as well as when shutting down.
No errors. And I just did a manual VALIDATE DATABASE with no errors, then
opened and closed all of the tables in the application, local and
shared, under that TABLEVALIDATE setting. Also no errors.
No errors; all reported USED() when they should be.
Is there some other quick test I should use?
>2. Review the last code change you made before the problems surfaced.
>That might have broken it.
The only change to all this code was an addition to the Error() method of
the Maintenance Manager class that will force a RETRY up to 5 times on
Error 1569 (I've had a rash of those lately too, and they seem to be
triggered, like Error 3, on USE commands, when the database should be open
implicitly SHARED due to SET EXCLUSIVE OFF.) However, that code change
doesn't run during the table validation routine where all the rest of this
happens because the table validation routine sets a flag that prevents it.
Maybe, though, during one of those RETRYs something else happens. Hm...
3. If it's not the software, perhaps it is the environment. You
mention an increasing number of users. That means new machines, OEM
configured, with settings that make VFP file sharing annoying to
impossible. I'll bet you would have mentioned if new users were the
only ones getting this error, though.
Yes, I would have, and they aren't. However, we replaced a bunch of XP
machines with Win 7 (Ultimate, SP1, 32-bit) boxes at the beginning of this
year.
The shared data resides on a serious-hardware CentOS (5.x, I believe) file
server running SAMBA 3, and the location is accessible to users as a mapped
drive. Hasn't been patched since it was installed several years ago. It's
all worked fine with Win 7 before.
There's a lot of ways a File Is in Use can sneak into the code. A
SELECT will open a filtered view of the table, aliased to the name of
the cursor, for example. For the time being, you might consider
patching the code with AGAIN on each USE to avoid the error and give
you some more time to track down the source.
Okay. Somebody else said SELECTs operate in their own data session.
If I understand correctly, the big picture logic is that the user
tried to search for a person, executing a SQL SELECT statement via
macro, something went wrong, the app shuts down (you claim the user
has to have hit the 'X' to close the window?), the app checks to see
if all users are logged off and if so, goes into a backup and
maintenance routine in which the "File is in use" error trips. Did I
get that right?
As best I can tell, nothing went wrong while the user was executing the
query that I can find. The user says they didn't get any error message, and
they shut down the program normally. I've seen three error reports exactly
like this recently, and the users all tell the same story. They never knew
anything was wrong. However, I can verify that users can see something
happen right in front of their eyes and say they never saw it.
The reason I mention the query is because it's in the stack trace from
ASTACKINFO(), which jumps from the macro execution line directly to the
main window's QueryUnload() method, which as I understand it, can only be
triggered if the user manually closes the window. (CLEAR WINDOWS calls
QueryUnload(), according to the help, but that command is not in the trace,
and it only occurs in my code very near the end of a shutdown, after CLOSE
DATABASES ALL, which should close all the tables. After that, nothing
attempts to open a table.)
If the user hit the 'X' during a query (how long do these take?)
perhaps you need to address this problem. Lock the window so they
can't close in the middle, or give them a "Cancel" that doesn't
involve application shutdown?
I've actually tried to duplicate this myself. The entire process from when
the user presses a button to do a search, through all the code that
constructs the SQL SELECT expression, and actual execution of the query,
return of data, and opening a window to display the results, can take up to
5 seconds or so, usually quite a bit less. I can just barely manage to
press the button to start the query and whip the mouse over to the main
window "close" button and press it before any results appear. If I do that,
I don't see any error message, and no log entry is generated. The system
just seems to forget that it was supposed to be executing a query and shuts
down normally.
I've tried this several times.
It's one of the reasons I'm mystified by the chain of events in the stack
trace.
But that's an idea to try.
My suggestion is that if the app is shutting down on an error,
shutdown. Lots of "stuff" gets left over in memory when an error
trips, and it's nearly impossible to clean up every possible setting
set awry.
Well, in this case the app thinks it's shutting down normally, and then the
error occurs during the stuff that it thinks is safe to do.
You are probably right that I should just ditch all this stuff though,
because almost all of the error reports I've been getting for the last
several months involve this subset of the code.
I've seen a lot of stuff on the web indicating that VFP errors allegedly
not related to file contention can in fact be caused by it under some
circumstances. That's what's got me most concerned.
Thanks for looking at this.
Ken
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox
OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech
Searchable Archive: http://leafe.com/archives/search/profox
This message:
http://leafe.com/archives/byMID/profox/[email protected]
** All postings, unless explicitly stated otherwise, are the opinions of the
author, and do not constitute legal or medical advice. This statement is added
to the messages for those lawyers who are too stupid to see the obvious.
