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 Westi on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Troublesome File Write Error in FoxPro

Status
Not open for further replies.

USMA99

Programmer
Oct 12, 2000
85
US
I have an error that can only intermittently can be repeated. I ran the same code on the same data a few times, sometimes it worked, sometimes it threw an error. (XP pro, VFP 9.0, heartily equipped workstation)

The line of code that trips the error is:
"COPY TO (cFileName) TYPE FOX2X"

As to the error, Foxpro reports a program error:
"Error writing to file [filename]".

It then gives a microsoft visual foxpro error:
"Fatal error 105 while attempting to report error 105."

In help I can't find a #105, however, I can find an error #1105 which says the OS had an issue while foxpro was attempting to write to the specified file. There is also something similar in the log on the PC. *Maybe* this is what the reported error was referring to.

I don't have a virus scan or backup running and can't find any reason that the file (which Fox creates and uses only for a a minute or two at most) should have a lock on it if that's the issue.

Does someone have an opinion as to whether this is indeed a FoxPro problem or not or what's causing this? I don't experience any errors outside of Foxpro so I'm having trouble ruling it out.

Thanks in advance


 
Can you manually create a file in the same location?
Is it possible that someone else has the file open already?


Regards

Griff
Keep [Smile]ing
 
What is the value of cFileName when the error occurs?
The error you reported occurs when:
1. cFileName is a DBF and the DBF is open by someone. (Multi User Network App)
2. Open in another work area (Single USer App)
3. The Directory in the Memvar does not exist.
4. The Directory exist but there is a Space in the Directory name.


David W. Grewe Dave
 
Usuaally the first error indicates some network failure. Are you writting this file on the Network? What kind of Network do you have - NT or Novell? So I agree with dgrewe here. Make sure the file is not opened with the same name.
 
What a wonderful error message.

It used to be quite common. Way, way, way back when, Richard Grossman dubbed it the "chicken bone" message:

"I'm choking on a chicken bone but I can't tell you I'm choking on a chicken bone because I'm choking on a chicken bone."

It literally means something is so f'uped in memory that VFP can't figure out what to report and in attempting to report *anything* it became confused.

And, hey, it's better than "Invalid BuffDirty" ;-)
 
Going along with the advice above you might try to test the file and/or erase the file prior to your write.

In that way you can determine if the file is in-use.

Code:
ON ERROR() DO MyErrorUtil  && Error Handler
IF FILE(cFileName)
   ERASE (cFileName)
ENDIF

* --- If Error Encountered Above, 'Copy To' Will Most Likely Not Work ---
*  ErrNum = 3  "File In Use"
*  ErrNum = 108  "File is in use by another user."
*  ErrNum = 1705  "File Access Denied....."
*  ErrNum = 202  "Invalid path or file name."
*   
SELECT MyDBF
COPY TO (cFileName) TYPE FOX2X

Good Luck,
JRB-Bldr
 
Thanks, but doesn't sound like we've found it, here are some responses to your reply questions:

In fox code I create the table from a structure, append some data, and copy out to fox2x. There's zilch chance someone else is grabbing it.

It's running locally on a box, no network involved

the file doesn't exist already (I've visually verified this)

the file isn't open somewhere else in the same program

the specified directory exists and is in fact the default directory at the time

I can do the copy operation manually, I can even do it in code ... usually

The value of cFileName doesn't contain space and is valid (I can vouch that the path/file is there at the time it crashed), for what it's worth the literal value which didn't work was "N:\FASTBACK\ORDERS\00337\PA003373.DBF" where N is a local disk drive.

I've actually tried purposely having a file in use while performing a copy to overwrite but it gives you a 'file in use' error and not the one I'm experiencing.

Any other ideas?
 
Also how many files in this directory already? Try to move them to another place.
 
I actually did a scandisk/defrag/checkdisk when this first popped up trying to rule out the PC, the error occured even after this

The directory starts with 3 files and about 20 are created (mostly small html files or other text files) with half of those in existence at the time this line of code bombs
 
we just started getting a similar error. We have built an internal source control that copies files back to master directory - if we run the exe that controls this, an errorcode 1 is returned. however if we go to command window and run, it works.......any ideas?
 
for what it's worth the literal value which didn't work was "N:\FASTBACK\ORDERS\00337\PA003373.DBF" where N is a local disk drive.

I'm still having questions here.
Seems like "N:" would have to be mapped first?
What type drive is "N:"?


David W. Grewe Dave
 
Hello Usma99;

In fox code I create the table from a structure,...

This may be totally unrelated, but I have seen this error like you have described (intermittently) when and if:
=Afields() is used and the table whose structure is being copied is still open, i.e. in a Browse

 
1. Try
copy to tmp fox2x
run copy tmp.dbf n:\destination
* do not put /n on the run command yet.



2. I suspect there is problem char in the code. It happened to me some time ago. The best is to view you prg file in debug or any other hexadisplay and trace that line.
Or create a new prg file and copy paste the code without 8 lines of sorrounding code. Then type those 8 line manually.

these might give you some clue.


try it

Nasib


 
Could your anti-virus s/w be interfering a little, I have had to put a short delay between copying things and reading the copy in some of my progs, because the OS/Anti-virus won't let the program grab the new object until a moment or so has passed?

Regards

Griff
Keep [Smile]ing
 
To answer dgrewe, "N" is mapped but is a local hard-drive, the box has 4 physical hard drives with a hot spare. The drive-mapping is just used since it's handier than the UNC path.

to imaginecorp, I'm not using an array at that point but actually do a CREATE TABLE FROM STRUCTUREFILE then use that file append data from a text file (all of that works) and then copy it out to a fox2x table which is where it *occassionally* bombs

nasib, I'm not quite understanding, "copy to tmp fox2x" is precisely where this crash is coming from. All of the work is done in a local directory so the 'final destination' is where the command would run from in the first place although I'm being specific as to the path with my cFileName value as a precaution.

to griffmg, I could do that but it actually bombs in "while" copying the data out. It starts to proceed (telling me there is no file lock) but then crashes mid-stream leaving a partial file. I could see a virus scan or some other processes trying to grab my file but IT swears that's not happening and I beleive them as it should happen at other places in the code that are sensitive to someone locking a file and not just this line of code.
 
Hi USMA99;

I mean not to use any variable for the file name,
use the syntax

copy to tmp fox2x

not

copy to tmp type fox2x

But now try this

copy to tmp
use tmp
copy to tmp2 fox2x
run copy tmp2.dbf n:\destination


good luck

nasib


 
While the TYPE keyword is optional in COPY TO, having it or not shouldn't make any difference and, IMO, the code is more readable with it.

Tamar
 
Guessing here: 2 things come to mind,
If you are using “Copy structure extended”, it may be bringing over .dbc stuff which obviously is not recognized by FoxPro v 2.n. i.e. when you are creating the table and appending data, it’s a VFP9 table so no problems, but when its being copied over…
When you create the table in code, is the Database (.dbc) open? Maybe the new table is becoming part of the .dbc and trying to export .dbc stuff. i.e. captions, rules etc. The reason this is “occasional” could be sometimes the .dbc is not “Set”, error sometimes not, no error. Auto increment fields are always a problem.
Try to create with only Copy Structure to and also Close all open databases, or better still Afields(), close the table if in a browse, then create your table with the keyword “Free”.
Unfortunately; it always works when I have tried to duplicate it.
Good Luck
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top