On 7/16/2015 9:21 AM, Ken Dibble wrote:
A quick-and-dirty solution is to check USED("_table_name_") before
issuing any USE _table_name_! Here is an example:
Thank you. I always do that. In fact, my framework has a data manager
class that handles this, so USE and SELECT are only issued in one
place. If USED() is .T., then I SELECT that work area.
I think you've decided on scrapping code. But here is a couple other
things that may help.
AUSED() - can return an array of all aliases in use (and you can specify
a datasession if you want)
DBC() - returns the path and name of the actual "file" that us
associated with an alias
So, if you build an array of aliases using AUSED() you can then loop
through the array using DBC() and log which file is actually used. This
works for cursors created by SQL queries too.
Assume I do "SELECT blah, blah FROM thattable INTO CURSOR wowow NOFILTER"
AUSED() would have both "thattable" and "wowow" in the array. Then
DBC("wowow") would return something like
"c:\users\temp\DZ0000AHCK33.tmp" whereas DBC("thattable") would have
"<file location of thattable>\thattable.dbf".
You could use the above as debugging steps or add to your framework of
checking.
Side note: A standard programming practice I've taken is to always add
the NOFILTER clause to my SQL. This ensures the resulting cursor is not
just a "filter alias" (a long time ago I think you could get a bit of a
performance boost if the resulting cursor was just a subfilter of the
source table, and indexed on the WHERE clause - but nowadays with loads
of PC memory, fast drives, etc, I don't think there is a reason to want
a "filter alias").
In case you don't know what I mean, consider:
*-- assume MYTABLE is indexed on a field "id"
SELECT * FROM mytable WHERE id=25 into cursor tempitem
USE IN (SELECT("MYTABLE"))
USE MYTABLE in 0 && this will error out because "tempitem" is
actually just an alias to MYTABLE with a 'SET FILTER TO ID==25'
*-- now with the NOFILTER
SELECT * FROM mytable WHERE id=25 into cursor tempitem NOFILTER
USE IN (SELECT("MYTABLE"))
USE MYTABLE in 0 && this works fine now because "tempitem" is its own
separate "file" - like "<path>\DF4QS000SD00.tmp" file
However, I have also seen this before, rarely, in other situations:
IF NOT USED("mytable")
USE mytable IN 0 && Error 3; File in use.
ENDIF
I kid you not. It's very strange.
I actually think there are processes in VFP that impose locks on
tables that aren't always detected correctly. In the above case, it
would seem that some OTHER user has the table open and locked for some
purpose. The error reported should be 108, but sometime's it's 3.
FYI in 100% of my tracing problems of this nature, it has always been
software code that caused the condition. In other words, a table got
opened exclusive, or I tried to open something exclusive that was shared
(and thought was closed), etc. An FLOCK() or RLOCK() will not prevent
another open in Shared mode.
Others may have already pointed this out but in your sample above, "USE
MYTABLE IN 0" will throw an error if the table was opened under another
alias. With the functions above, you could easily determine if the table
is actually open or not.
Also as others have mentioned, other applications can lock files (like
AV). Plus, if you allow ODBC access to the tables I think the it
defaults to EXCLUSIVE when trying to pull data (not sure though, and it
can be changed).
-Charlie
_______________________________________________
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.
