Invalid Path error when copying cursor to text file for graphing with MS Graph

[ontsjc]

Hello All,

A program I have run for several years now has suddenly developed a strange error. I'm running FoxPro 9 on a windows 7 machine. I've been using MS Graph to run several hundred graphs a quarter for a few years now and have had no problems. All of a sudden I'm receiving and Invalid Path error when I copy a cursor to a text file to feed the graph. The offending line is:

COPY TO (workdir)+'graphmake.txt' TYPE DELIMITED WITH tab

where workdir is a varible defining the file path. When running these graphs, graphmake.txt is simply overwritten each time to make the next graph in the sequence. When I receive this error, I have to mannually delete the graphmake.txt file, and then the program runs fine again for awhile. The problem seems to crop up randomly. Deleting the file from inside the program does not seem to work. This error has only been happening since the beginning of this year. Previously, there seemed to be no issues. The MS Graph template is held in a general field and then once the graph is created it is appended to a differnt table's general field where the graphs hang out until I print them all off.

Any thoughts would be most appreciated.

 

[EzLogic]

I am suspecting you have a violation error. if the file is in use, you cannot just copy over it.. nor can you delete it.. hence you have the issue with deleting it.

somehow you have to release the file and then you can write over it.

Ez Logic
Michigan

 

[Olaf Doschke]

What folder are you writing to? Inside /Program Files/?

Bye, Olaf.

 

[Olaf Doschke]

Good point from EzLogic.

You can write files in parallel, if using random file names. Use SYS(2015) for that, eg lcFileNameGraphTXT = (workdir)+'graphmake'+SYS(2015)+'.txt'
Then pass on lcFileNameGraphTXT to the MS Graph control. And finally remove the file, when not needed anymore, but not earlier. An easy thing to do is ERASE (workdir+'graphmake*.txt') at program start or end. It will only ERASE files not in use and it will not error when processing a file still in use, and instead continue erasing further files.

Bye, Olaf.

 

[Mike Lewis]

I agree with EZ and Olaf. I would add one small point: Instead of workdir, use the directory returned by SYS(2023). This is the user's temporary directory.

Doing this won't affect the logic of the program in any way. But it does have two minor advantages: (i) The directory is private to the user, so there's no chance of another user overwriting the file; and (ii) If you fail to delete the file for any reason, it can still be removed at some point by the Windows cleanup tools.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Koen Piller]

Hi,

you are copying a cursor to a specific directory? Why is that? A cursor is by default constructed in the temp directory. I believe that if you have your workingdir(ectory) in your path you will not have to move your cursor at all.
What is your pathsetting?

Regards,

Jockey(2)

 

[JRB-Bldr]

Another issue that I have run into that has caused a similar problem is forgetting to end my path definition with a trailing slash ( '\' ) before concatenating the file name.

Therefore I use the ADDBS() function around my path definitions.
If the trailing slash is present, the function is ignored.
If the slash is missing, the slash is appended.

So your original command would become something like:

COPY TO [b]ADDBS[/b](workdir)+'graphmake.txt' TYPE DELIMITED WITH tab

Debug hint: Insert either a Breakpoint or the code SET STEP ON just before the COPY TO command and examine the expression value(s) in the WATCH Window.

Good Luck,
JRB-Bldr

 

[Mike Lewis]

Therefore I use the ADDBS() function around my path definitions.

Or, better still, FORCEPATH().

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[ontsjc]

Thanks everyone, using the sys(2015) seems to have done the trick. I also added the ADDBS() just for good measure. This is just a little prg file for my own personal use, so it never ends up in a shared environement. It still is strange however. I've used this for years and never had this issue crop up. However, I'm not entirely in control of my computer here at work and don't have a great deal of say over updates. Is it possible that operating system updates, or monitoring software could have triggered this error?

 

[brigmar]

Check out the Microsoft sysinternals utilities.
In particular interest are Process Explorer, which will allow you to determine which files a process has open, and psfile which allows you to determine which users have files open.
This may not help if the culprit is anti virus software, as I have seen cases where a file being locked by AV software does not register.