Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Checking who is using a file

Status
Not open for further replies.

androidc

Programmer
May 27, 2003
13
CA
The software I'm working on right now can have multiple users. But each user needs a copy of a resource file, that we call RES___

On a network, there can be many users, each user will have a copy of the file RES___ which is named RES001, RES002, etc.

When the user logs on, the file is copied from the original RES___ using
Code:
COPY TO ( _resource )
Naturally, _resouce contains the path and file name (ex _resource = "c:\blah\RES001.dbf") to be created.

On a particular client's system, they are getting error 1705: File access denied on the COPY TO command.

I would like to be able to test and see if the file is in use by another program. Checking read-only attributes doesn't work, because I can still get the error even if the file is not read-only (but apparently open by something else).

The test i tried is to run our software, and before creating RES001, i opened RES001 (exclusively and shared..tried both..) in another instance of foxprow. Before copying, i check the attributes, read-only is not there, and i get error 1705.

If I run the software normally, that is, without opening RES001 prior to creating a new instance, i can get in fine. Even if the file exists, it's overwritten.

I figure, if I can gather information about what is keeping the file open, then I can get this problem off my desk. It's been around for awhile. So far, when I need to solve this problem so the clients can use the number of licenses they purchased, i've rebooted the machine. Which works for a day, an afternoon, not very long.

One could say that the files aren't being closed properly, but then we'd be seeing this problem with all our clients.
With at least 200 other clients using the same software without this problem, its a strange case, one that's eating up a lot of my time.

Oh, Microsoft's Terminal Server is being used by the client, for some of the users who are outside the city to use the same database. I've spoken with the admin of the client's network, and he's assured me that all users close Terminal Server properly, and even then there are only two who connect maybe twice or thrice a week. (by properly i mean logging out and not closing using the x in the top right corner of their Server window.)

To recap, i'd appreciate any help in finding a way to find out what program/user is holding access to the file in foxpro2.6 code would be greatly appreciated.

Thanks
 
Here's what I use to check the 'openness' of files:
Go to: and look for WhoHasIt and WhoHasNT.

Chances are the file status may not be getting updated after it is closed. Maybe you can test for the file availability using something like:

STORE 0 TO nHandle
nHandle = FOPEN("RES1.DBF", 2) &&... read /write
IF nHandle < 0 &&... open by someone
*... 'Already open' message here
RETURN
ENDIF
=FCLOSE(nHandle)

*... rest of startup code here


Dave S.
[cheers]
 
Error 1705: File access is denied... You have attempted to write to a file that is write protected.

At first I was going to ask about network rights? Does the error happen if another user is logged on at the workstation? If not, then check to see that the user has the appropriate rights where he's reading from.

The error, though, occurs after you've already opened the original table and seems to have a problem with the destination table, apparently writing onto the C:\ drive, which should not be a matter of network rights. (Or is it? If this is NT, 2000 or XP, does the user have rights to that directory?)

Also, check to be sure the full path exists, as FoxPro probably cannot create the directories with the COPY TO command. If there is already a copy of the file there, check it's read/write attributes. Can you delete the offending file? You can remove it, since it is overwritten every time the program starts, as I understand it.

As a last resort, if nothing else makes sense, I reboot and try again. Good old Windows solution.

Try scandisk too to rule out file system issues.
 
If the client is using Windows, check that he is not running the program in two instances
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top