FP 2.6 failure - different scenario

[Dirtless]

Hello;

A coworker has been trying to run an old application and gets an error message:

"A temporary file needed for initializaion could not be created or could not be written to. Make sure the ... path exists and space is available. Choose close to terminate"

It is running on a relatively new machine (HP) with Windows XP SP 3. I can run the same application exactly, same OS, albeit on a somewhat older box.

Thanks

D

 

[JRB-Bldr]

Same answer that I gave on your other FP 2.6 Failure posting....

Try running from the FP2.6 Command Window to see where things 'go south'. That should pin-point where action needs to be taken.

Good Luck,
JRB-Bldr

 

[Dan Freeman]

Which version of FP2.6? (i.e. DOS or Windows?)

The usual answer to this was "you're missing a foundation read", but since this is an established application I don't think that's the likely answer.

Win XP/SP-3 was the first version that introduced security protections. Is it possible that your user used to run as an administrator and is now, on the new machine, running as a restricted user?

 

[Dirtless]

Danfreeman;

2.6 for windows, and nope - there is no way he had admin rights.

Thanks

D

 

[JRB-Bldr]

In general FPW2.6 runs just fine under XP.

"A temporary file needed for initializaion could not be created or could not be written to. Make sure the ... path exists and space is available. Choose close to terminate"

The error message is implying that something is missing which is required.
Whether that 'something' is R/W access rights or a missing directory or a missing file, or even a core component of FPW, we cannot say without knowing the various specifics of your application.

If this problem is coming up during the launching of the application itself, I'll repeat my previous suggestion - try to run the application from the Development mode and see where the problem crops up.

Good Luck,
JRB-Bldr

 

[Dirtless]

Thanks for your input JB

My problem is that I am unable to install FoxPro on the machine giving us the problem, and therefore have no command window to work from. (The application is compiled into an executable file.)

I have tried adding a config.fpw in the directory containing the program file, using the tmpfiles command to force a temporary folder that we know can be written to. No success.

D

 

[JRB-Bldr]

OK, if you are unable to install FoxPro on the machine giving us the problem then can you create a mew FPW2.6 application (EXE) solely for debugging purposes which will follow the same application environment setup path, but uses multiple WAIT WINDOWS to allow you to sequentially watch the progress and determine how far things went before it 'blows out'?

Install it on the problematic workstation and watch its progress.

Good Luck

 

[Dirtless]

Tried that. Splash and then back to the desktop.

D

 

[DSummZZZ]

As you mentioned in your other thread, you tried altering the config.fpw to change where temp files went, but you didn't say whether or not that directory had sufficient rights.
Even if there is sufficient space, Fox needs to be able to write and delete temp files at runtime.

You may try creating a new directory with 'Full Control' rights for the user, then build a simple exe like jrbbldr suggested and put it and the runti,es in that directory.
Then add a config.fpw with TMPFILES= pointing at that directory. That will at least eliminate a rights issue.


-Dave Summers-

Even more Fox stuff at:

http://www.davesummers.net/foxprolinks.htm

 

[Dan Freeman]

OK, wait a minute.

If it's a new machine, how are you installing the app? The exe alone WILL NOT be enough.

 

[Dirtless]

DS and Dan;

Appreciate the suggestions.

DS - I did create a super simple application and used it in conjunction with a TMPFILES command in the config file - same result.

And Dan - For installation we've followed the same route we have for a decade - copy the exe file plus Foxw2600 (everything patched) into a folder and run it from there. We tried running it from Windows Explorer AND also from an icon.

D

 

[TamarGranor]

I wonder whether this book might help you figure it out:

http://www.hentzenwerke.com/catalog/painless.htm

Tamar

 

[Dirtless]

TamarGranor

I found a PDF of an applicable section of that book on line. (Some people are apparently not big on copyright and such.)

I've tried one of his suggestions thus far - specifically forcing the program to run in it's own memory space. I thought this might work, as increasingly I am being pointed in the direction of some sort of memory conflict, or similar problem.

Didn't work. Splash and gone.

To reiterate where I stand at the moment, we have identical XP SP3 boxes, set up and administered by the same people, with the compiled application developed in a 16 bit environment (using FPW 2.6). The executable file then is copied to a folder with the support library (Foxw2600.esl); both files have been patched.

Thus far we have had two installations fail. Here are the efforts we have made at fixing the problem:

We have tried modifying Config.fpw to force writing temp files to a folder to which we know we have full access rights. (That used the Tmpfiles command.) We have tried adjusting the program's compatibility mode (to both Windows 95 and 98). We have tried forcing the program to run in it's own memory space.

My next steps will be two fold: I am increasingly leaning towards memory issues, and will continue researching that line of thought. I have also been led in the direction of consideration of Config.NT and Autoexec.NT. While I plan on reading further any action will require the cooperation of our system people, and will be more difficult to test (for logistical reasons).

And I am open to any additional suggestions.

D

 

[Dan Freeman]

So, in summary, you have side-by-side WinXP machines. The application runs properly on one, but not on the other.

The failure, obviously, lies in the difference.

You can rule config.nt and autoexec.nt in or out by looking on the working system to see if there is any customization there. If there isn't, then that isn't what's holding you up.

Rather, focus on the differences between the systems. Memory? Installed printers? Video drivers? (Drivers, in general, have always given Foxpro conniptions.)

You're looking for the delta between working and non-working systems.