READWRITE can also be used to guarantee you are not getting a filtered view.
-- rk -----Original Message----- From: ProfoxTech [mailto:[email protected]] On Behalf Of Charlie Sent: Thursday, July 16, 2015 7:22 PM To: [email protected] Subject: Re: "File In Use" on USE "during" SQL SELECT Execution 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/bn4pr10mb0913b7fbf16388186ff3cd6bd2...@bn4pr10mb0913.namprd10.prod.outlook.com ** 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.
