Listmates,

Have a situation where files are opened on the fly. Central routine handles all opening and closing.

There is code that detects if the file being opened is already open, it closes then opens the correct dbf.

Recent changes to the website has spawned infrequent error where VFP reports back that the file in question is in use. So, in essence the process to check to see if that file is open failed. I believe this is coming from a cursor that has been opened and not closed.

I am considering cutting in code that uses AUSED() to cycle through all the files opened and using DBF() to determine the real name of the file. Should I find a match ... close the file before opening.

Any thought on this will be appreciated.

I assume your central opening routines do this, but you should be doing something along these lines for all cursor open operations.

IF !USED("Customers")
   USE Customers IN 0
ENDIF
SELECT Customers

If you're consistent with this this is a pretty surefire way to ensure that you don't get into trouble for using tables.

However, your issue sounds more like a problem with EXCLUSIVE use - FoxPro will reuse tables and even allows opening the same table in multiple alias's simultaneously. So the issue more than likely is that a table is either locked or in EXCLUSIVE use.

+++ Rick ---

Rick,

That is similar to the code I'm using. Checking to see if the file is open first. Then if it's not detected, open the file. However, opening the file then returns 'File in Use'. It rarely happens, actually only 2 times just in the last month.

Because I can't track where the offending process occurred as this is a central opening/closing process. The files being opened are being passed in via parameter.

My guess is that it's a stray cursor that wasn't closed properly. FYI each client has there own data sets. So I have to ensure they are getting the files that belong to them.

As such, that's why I am considering using the aused() funciton to get list of files then subsquently using DBF() to determine the actual file.

Thanks for your thoughts.

File is in use should never happen if files are opened shared - so if that happens somewhere a file is either:

1. Opened exclusively
2. Open with a file lock

There's nothing you can do about #1 other than not opening files exclusively. Really you should never open files exclusively except when doing certain admin tasks in which case you should ensure the application is the only one running (ie. blocking all other users or instances).

#2 can be mitigated to some degree with SET REFRESH by increasing the timeout limit so that the wait between access attempt and failure is a little longer. The default is very short (1 try). I tend to use SET REFRESH 2 SECONDS which is long but in theory that should really rarely if ever trigger.

+++ Rick ---

Rick ... just a follow up. All files are opened shared through a central routine. What I found was indeed the file was opened VIA Select to a cursor, without a readwrite, and the cursor was not closed. Took bit of digging but in fact, that what the issue was. I didn't have to resort to cycling through the files used to see if they matched the name of the file I was using.

Thanks again.

You can always do SELECT FORCE to force the result of a query into a new temporary table rather than filtering the original table.

Regardless though - that should open the file in SHARED mode, not EXCLUSIVE so it seems odd that this would lock your table.

+++ Rick ---

Hi Rick, You are mixing Force with Nofilter. BTW, I always use Readwrite instead of Nofilter, it does the same job plus it makes the cursor updatable.

Yup right - nofilter is what I meant. There are potential side effects and behaviors with readwrite and change tracking overhead, so for most cursor use cases nofilter is the way to go - I would reserve readwrite for cases where you explicitly need to update the cursor which in my experience is relatively rare. Most cases you update data in the underlying data not the cursor copy.

+++ Rick ---

I once was told (Calvin?) that the difference between Nofilter and Readwrite internally was just a bit setting, and that there was no reason to ever use Nofilter instead of Readwrite. You never know when you need to alter some of the data in the cursor, and if you have used Nofilter, you have to find that line and edit it. Just a good tip..