dBase 5.0 for DOS "File Already Exists" error message

[Nate Walz]

I am encountering an intermittent error message when using VDOS and running dBase 5 for DOS programs. The problem appears sometimes when I modify a program, and then try to compile it or run it. I will receive this error message:

In the program directory before I modify the program, you can see the file "files.dbo" exist:

After I modify the .PRG and save my changes, the .DBO file disappears.

I have tried to shutdown, log-off, restart, and nothing has proven to work. I will stop using dBase for a day and come back the next day, sometimes it works, sometimes it doesn't. For the last 2-3 days I have not had any problems. Please let me know if you have any suggestions. So far this is only happening on my local laptop where I modify programs. When this occurs I can still use my old XP laptop that is running MSDOS to modify programs, and then copy to our LIVE server.

Thanks,

Nate

[Nate Walz]

I have also noticed that once this error message starts, I can try to compile a .PRG and the associated .DBO will disappear. I don't even have to modify the program.

[Jos]

I never programmed in xBase…

“File already exists” seems something the NATETEST procedure/program displays.

“… sometimes it works, sometimes it doesn't.” doesn’t clarify much; PC’s and programs (certainly DOS ones) are known to be rather consistent.

No idea, but what if you delete the .dbo file before starting vDos?

You could start vDos with the log option (“…vDos.exe” /log). Maybe the generated vDos.log file will reveal something (regarding the .dbo file?).

Jos

[Claude]

Hi,

We have the same issue with dBase 5 on a few emulators, this seems to have been fixed in vDosPlus version 2017.08.01 (build 2018.03.01) its working well. the issue we have with vDos and vDosplus is some sort of locking issue.

we have programs that poll for files and then do the work and return a txt file. sometimes we can not read the txt file for 5 seconds, in real dos or dosemu this is working in under a second. it would be really helpful if you can have any idea as to why this is random on vDos.

I have tried windows 10 / server 2012 r2, ntfs drive vfat drive.

Regards,

C

[Jos]

Those programs run in vDos, create a txt file w/o problems, you cannot read that file outside the program for a period of time?
You know the text file is present/created, but you cannot open it?

If the first program closes the file, all locks and open mode restrictions are immediately released by the OS hosting the file.

Jos

[Claude]

Hi,

Thanks for your reply, it's difficult to explain, sometime there is a five second lag that is only in this emulator, we have a web server that is waiting for dbase to output a txt file and a htm file, the txt file is always written first. this normally takes under a second, in vDos it is random the same request can take a second but mostly it is taking 5 seconds, something different is happening in vDos than real dos or dosemu. I really like this vDos it is way better to deploy and manage than dosemu, but really need find a fix for this speed issue.

Regards,

[Claude]

the file is there, as the htm file is there, but the web server can't read the txt file for 5 seconds, its like its staying locked in the emulator or windows, hence trying vfat over NTFS etc. the share on the server is fully open.

[Jos]

The txt file is created, its data written, file closed, then the htm file is created, its data written and file closed.

Or the txt and htm file are created at the same time. The web server detects the txt or htm file is created, but has to wait until the dBase program finishes writing the txt file. So it’s a matter of dBase running slower in vDos than in real DOS or DOSEMU?

The disk format should have no influence to the locking mechanism of the OS managing the drive.

Jos

[Herman]

Hello,

I had that long time ago also.
The txt file that was created is not right closed.

SET CONS OFF
SET PRIN TO FILE (<filename>)
SET PRIN ON
? <your code or text you want>
?
SET PRIN OFF
CLOS PRIN
SET CONS ON

CLOS PRIN directly close the file if
SET AUTO ON (writing direct with no buffer in dBase)

Greeting Herman

[davidson]

I also had the "File Already Exists" problem when compiling .prg files
I think I got it solved by using "set development on" command

[davidson]

I am having this issue also.
"File Already Exists"
Dbase application will not generate a dbo file for a new or modified .prg file.
It is really frustrating and I cannot find a solution.
Even when all .prg and .dbo files under this file name are deleted and a new .prg file is saved the problem is still there.

[davidson]

I thought "set development on" fixed it but it did not
Suggestions will be greatly appreciated

[herman]

This have nothing to do with vDos.

Its a dBase ""bug""; its also in the Windows x86 cmd.exe

I also sometimes have this problem with compiling to dbo and make exe.
There is not a real solution for this.

If you get the message, then you click ok and set behind the prompt do <prgname> (if you in the right path were the program is)

Mine message File already exist comes not on the second run and it compiles as espect.

If have tried much commands like Close data, close file or somthing like that and it doesn't work

For printing something, I use close print earlyer sad here above

[Jos]

You had a look at: vdos.proboards.com/thread/331/correct-after-copying-older-files?page=2?

Jos

[Jos]

Addition:

If the file is deleted while a DIR API command is still in effect on the same directory, weird things happen in Windows. A DOS FINDFIRST with a wildcard (creating a Windows search handle), and no failing DIRNEXT closing that search handle. Windows will then only mark the file as pending for deletion. A test for its existence will fail, you however still cannot create a file with the same name in that directory .

The DOS program isn’t really to blame. Though you would have to do a file cleanup before vDos starts.

Jos