File does not exist 1

[bjitima]

We have a program running with Foxpro 2.6 for DOS that is doing something that we can't explain and I was wondering if anybody else had seen anything similar. We are currently running it on a Windows 7 PC.

The program creates a text file from a directory listing, then creates a table with a single 12 character field. It then checks to see if the text file exists and if it does, it appends the contents of the text file into the table. When it is finished appending, we delete the file. However, once or maybe twice a day, we are getting the "File does not exist. Cancel Suspend Ignore" error message on the append command. We JUST created both the text file and the table, so how could the file no longer exist at this point? We thought perhaps another program was deleting it (we were originally using tmp.txt) so we changed the filename to card.txt, and then card.fil when it continued.

! dir &vdrv.\mailbox\*.dbf > &vdrv.\mailbox\card.fil
sele sele(1)
create table &vwpath.infile (line c(12))
if file(vdrv+"\mailbox\card.fil")
[highlight #EF2929] appe from &vdrv.\mailbox\card.fil sdf for upper(line)="CARD" and ;
upper(right(line,3))="DBF" and val(substr(line,5,4))>0[/highlight]
if file(vdrv+"\mailbox\card.fil")
dele file &vdrv.\mailbox\card.fil
endif
endif​

 

[bjitima]

 

[Olaf Doschke]

Do you have a card.fil in your source project? FILE() returns .T. on files included in your EXE. A better weay to ensure a file is really on HDD is using ADIR(): IF ADIR(laDummy,vdrv+"\mailbox\card.fil")=1 instead of IF FILE(...).

I don't know if ADIR is available in FPD2.6 at all, but if it is, you could use it instead of the DOS dir command, that would be even better solving the problem.

Bye, Olaf.

 

[Olaf Doschke]

ADIR(laDBFs,vdrv+"\mailbox\*.dbf") would give you an array of DBF files on drive vdrv in the mailbox folder.

Bye, Olaf.

 

[bjitima]

To answer your first question, there is no .EXE with a source project. We are actually running "c:\fox\foxprox.exe -t card.prg"

I think ADIR() is definitely better solution than continuing to run it as is, but this worked previously for quite some time and we just couldn't explain how the file could suddenly not existing immediately after checking to see if it existed.

 

[TamarGranor]

I'm suspicious of any use of the macro operator in file names. If the content of the variable has any embedded spaces, things will go wrong.

Tamar

 

[Olaf Doschke]

The new part is Win7, isn't it? The OS behavior in regard to files changed. You're not the first having file not found issues. More prominient are problems with PACK, as that also generates new files. Another player in the game is antivirus software inspecting new files.

So you better switch to ADIR()

Bye, Olaf.

 

[NasibKalsi]

1. Try adding some delay before appending

wait "Before appending"

or

= inekey(5000) && Wait for 5 seconds before appending

2. Try copy the file to default directory where you do not need to fully qualify the file name.

3. Add some delay before deleting as well

 

[octavian2006]

When you write "if file(vdrv+"\mailbox\card.fil")", after the vdrv it is no point (vdrv+"\mailbox),
but when you write "appe from &vdrv.\mailbox\card.fil sdf for upper(line)="CARD"", after the vdrv it is a point (vdrv.\mailbox).

Maybe this is the problem?


Octavian

 

[Olaf Doschke]

No Octavian,

The point in &vdrv. is marking the end of macro substitution, it's not part of the final strting. It's optional, if the next character also makes clear the variable name for macro substitution ends, eg a space or + after the variable name makes the dot optional, but try it yourself:

vdrv="C:"
? "&vdrv." & doesn't show a ".", just "C:"
Modify File &vdrv.\Windows\win.ini

Bye, Olaf.

 

[dbMark]

Do you use a filer? If so, that could be the issue. We had a filer upgrade last April that immediately caused two issues. The first one,thread184-1734316, dealt with the "?" search wildcard that worked when kept separate such as "A?B?C?D?.?X?" but failed with "AABBCC??.TXT". It's been fixed.

We still have an issue with occasional "File not found" errors. Personally, I'm speculating that something is wrong with the order of precedence. If the commands are being parceled out to separate threads, could one be getting done before the prior one? Just guessing. Of course, this means nothing in your case if you don't use filers.

 

[Olaf Doschke]

dbMark might have the right idea. Inside VFP you have to trick to start a new thread, but functions that go down to the OS level like file functions could be processed in separate OS threads or even processes. I still guess it's a OS issue, since that sort of errors were not reported on XP, but it might also be related to multi core CPUs.

Bye, Olaf.

 

[dbMark]

How about using a TRY|CATCH|ENDTRY so when it errors then you SLEEP for a fraction of a second or even longer and then try again? Maybe after a brief delay the second time around it will 'exist'. If it fails at first but works a few moments later then that might be the answer.

 

[Dan Freeman]

Try/Catch/Endtry were late additions to VFP, much less versions earlier than VFP (which is what we're discussing here).

 

[Olaf Doschke]

The oldstyle TRY/CATCH can be done by ON ERROR lnError = ERROR(), init lnError as 0 and check after append, if lnError>0 and if so wait and retry the append.
But since bjitima has left this on september 2nd, I think it's solved anyway.

Bye, Olaf.