Low Level Files

[spayne]

Our data entry people to use an MS-DOS program to enter data and create a ".dat" file with the name of the current date, ie "09-12-01.dat". This file is then processed by this MS-DOS program to create a report.

I created a VFP6 program to create this ".dat" file, using fcreate(), etc. When this file is placed in the appropriate folder and the MS-DOS program is run, a "File Not Found" error is issued. The file is there, and it is named appropriately. Could this have something to do with the fact that the file was created in the Windows environment? I know this is pretty vague, but if anyone has any ideas or whats more information, please respond.

Steve

 

[IanWh]

Hi spayne,

You shouldn't have any problem doing what you're doing. There's nothing about files created in vfp under windows which would make it unreadable by an msdos application. The only two things I can think are:

1. the file is simply named incorrectly, make sure it's not got a long file name (it needs to have 8 characters followed by a dot followed by three charaters (dat in your cas) Or the file could be in the wrong directory ( I know you said you've check this, but I'd check it again personally)
2. The is still open, did you use an fclose() in your vfp application? Is the vfp application still running when you try and run the msdos application? DO an fclose(m.filehandle) or a close all, or quit the vfp application and then try again.

Ian W.

 

[dgrewe]

Make sure the "0" is in front of the "9" in the file name.
DOS can not file a file that begins with a blank. David W. Grewe
Dave@internationalbid.com

 

[spayne]

IanWh,

Thanks for the hints, but everything you have suggested has been checked and rechecked. The file name is always the current days date with a two digit year, ie "09-13-01.dat".
I use fclose(lnHandle), and the file is definitely in the correct directory.

Steve

 

[spayne]

dgrewe,

There is a "0" in front of the "9", but I am guessing that it has to be something as simple as this, something I am overlooking, because it's not that complex of a problem. Yet everything looks just perfect.

 

[spayne]

Problem solved. The data entry person told me which folder the file needs to be in. Turns out she was wrong. Imagine that!

Thanks for the suggestions, though.
Steve

 

[csr]

Since Spayne seems to have missed it ...

Thanks IanWH for the correct answer (see earlier response).

Don
dond@csrinc.com

 

[spayne]

csr,

You are right, if I hadn't already addressed those problems before his response, I would have looked into it. But as I have already responded in this thread:


>IanWh,
>
>Thanks for the hints, but everything you have suggested >has been checked and rechecked. The file name is always >the current days date with a two digit year, ie "09-13->01.dat".
>I use fclose(lnHandle), and the file is definitely in the >correct directory.
>
>Steve


Steve

 

[ramani]

Hi spayne,

I understand the strage thing happening. I have faced similar issues myself. In my case, the causes were...
1. Any long file name,,, getting ~1. or ~2...
WHen this happens, I ended up in problem. So I handled that by never exceeding 8 character lenth.. This is not your instance here.

2. The case sensitiveness of the OS was the other reason. When you look at the directory, some files could be in upper case and some in lower case. In a strange circumstance, my lower case file names were never recognized by DOS application (that was pkzip). May be you are having a similar situation. RESOLUTION.. ensure that your file name is in upper cases .. rename the .dat file as .DAT file and chechk the results.

3. Also the following can be a reason... Instead of using yy-mm-dd... use YYMMDD.DAT I am not sure if the dos interpreter does an evaluation under misterious circumstances !!!

Hope this helps you.
ramani :-9
(Subramanian.G)
FoxAcc
ramani_g@yahoo.com
LET KNOW IF THIS HELPED. ENOUGH EXPERTS ARE HERE TO HELP YOU OUT! BEST OF LUCK