Clipper File Open Error

[chas]

Trying to setup vDos to run a compiled Clipper application since we are moving from Win 7 to new Win 10 64 bit machines.   

If I manually set the environmental variable for the number of allowable database files to be open ( ie: Clipper=F45 ) and map my drives properly my application works just fine, at least for the little I've experimented with vDOS so far. 

If I then put the same commands needed to run my app into an autoexec.txt file that I manually ran from the command line, (so my users don't have to manually set the drive mappings and Clipper Files variable, etc),  then my Clipper application gives me an "Open File Error" stating that it can't open all of my database files. 

If I then abort out of the Clipper app with the vDOS box still open and manually run my Clipper app a second time (same commands that are in the autoexec.txt file), everything works fine and I don't get any file open error.  This is repeatable. 

Anyone have a hint as to why this is ?   Seems like the Clipper=F45 variable is being set in the autoexec.txt file execution but after the program fails and I abort out if I type in "Set" it shows that the variable exists?

This is the simple contents of my autoexec.txt file.

@echo OFF

SET CLIPPER=F45

SET PCID=1

USE N: \\vts2\data\vts dos data

USE O: \\vts2\apps\vts exe

CD N:
O:\Main1

CLS

echo on

rem exit


Help,   I have a small window to get this running before new PC's are installed.

Thanks,
 C~

[chas]

To add to my evaluation, it appears that my other Environmental Variable  ( PCID=0 ) is also not being recognized even though it shows when I enter "SET" at the command prompt and see it listed.   We use the environmental variable PCID to set security levels to a number of menu options and with the highest security clearances I can't access many menu items as the Clipper App is not seeing the PCID environmental variable. 

C~

[Jos]

Strange things happening. It should of course not matter whether you enter the commands at the command prompt or put those in autoexec.txt.

No real clue, what if you add a line with PAUSE before O:\Main1?

Also don’t know if SET CLIPPER=F45 is active, the number of file handles can be ‘hard linked’ into the executable.
Or if "Open File Error" actually means the number of claimed file handles are exhausted.

Eventually start vDos with the log option (….vDos.exe /log), and have a look at the generated vDos.log file. Perhaps that reveals more.

BTW, you can omit:
@echo off (will for now also display the executed commands before PAUSE)
CLS
echo on

Jos

[Jos]

Addition:

I noted "...into an autoexec.txt file that I manually ran from the command line...".

Autoexec.txt is executed as vDos.exe starts, you cannot execute that from the command line.

So my guess would be you start some autoexec.bat, NOT autoexec.txt. Put that in the directory of vDos.exe, or adjust the Start in directory of the shortcut starting vDos.exe (to that containing autoexec.txt).

Jos

[chas]

Thanks for the quick reply. Tried both of the above to no avail. What I ended up doing is copying the vDOS executable, Autoexec.txt file, and my Clipper compiled executable directly into the same folder as my dBase (Clipper data) files and I was able to get it all to work. Had to setup IF statements in my Autoexec.txt file to distinguish security levels based on each %%username%% returned and in some respects easier than running from the C:\vDOS folder on the local machine. Initial testing works for opening the required files and loose security.... now for more testing.

Thanks,
C~

[Jos]

It’s always best to have only one copy of vDos.exe on the network, so in some directory on the server. And as little as possible config.txt and autoexec.txt files.

I now also notice:
USE N: \\vts2\data\vts dos data
USE O: \\vts2\apps\vts exe
CD N:

Shouldn’t the last line not be N:, selecting the N: drive?
CD N: basically doesn’t do anything: Set the current work directory of N: to the current work directory of N:

Jos

[chas]

Thanks Jos, I must have had a brain blip, yes should be N: not CD N: Sometimes we can't see the forest for the trees.