Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, January 7, 2013 9:22 AM
Hi all,
There is a Config.fpw and Temporary files folder is set as 'TMPFILES = C:\TMPFILES' in my VFP application folder. But somehow default temporary folder path is set for VFP and when running the application it displays some files not found in windows default temporary folder (The folder which is set in Tools- Options - file locations in development)
Eg:In my development the vfp Tmp file location is set as 'C:\Docume~1\Machine1\Locals~1\Temp' and I have a config.fpw and there the temporary file path is set to C:\TMPFILES. But when I build an EXE and run it in another computer it throws errors saying 'error reading files in C:\Docume~1\Machine1\Locals~1\Temp path'.
I couldn't find any reason for this. Why it is not consider the settings in Config.fpw file ?
What might be gone wrong here? Can anybody give any suggessions regarding this?
Please help
Best Regards
All replies (34)
Wednesday, January 9, 2013 2:20 PM ✅Answered | 1 vote
Best idea...don't change the setting at all in Config.fpw. Delete the tmpfiles setting. Then, VFP will use the default Windows temp folder.
Craig Berntson
MCSD, Visual C# MVP
INETA Community Speaker
www.craigberntson.com
Monday, January 7, 2013 11:41 AM | 1 vote
Hi all,
Regarding the above issue I can give an example for this.
Eg:In my development the vfp Tmp file location is set as 'C:\Docume~1\Machine1\Locals~1\Temp' and I have a config.fpw and there the temporary file path is set to C:\TMPFILES. But when I build an EXE and run it in another computer it throws errors saying 'error reading files in C:\Docume~1\Machine1\Locals~1\Temp path'.
I couldn't find any reason for this. Why it is not consider the settings in Config.fpw file ?
What might be gone wrong here? Can anybody give any suggessions regarding this?
Please help.
Best regardsf
Monday, January 7, 2013 1:10 PM
Assumption: the directory C:\TMPFILES does not exist on the target machine. Then it's not generated and VFP falls back to the system default of GETENV("TEMP"), which is the users local temp files folder.
Users should have sufficient rights to read AND write in that folder, so that shouldn't be a problem in the normal case. Your customer seems to have restricted the users, which is not a good idea, not only in respect to VFP applilcations.
Bye, Olaf.
Monday, January 7, 2013 9:34 PM
What file is your application attempting to read from the "original" temp drive?
What command reports this bug?
Monday, January 7, 2013 11:58 PM
In windows, the temp directory is set/changed under
Control Panel - System - Advanced - Environment Variable....
Look for the variables TMP and TEMP
Some directories might be read-only, under Windows Security level, due to users not be Administrators, etc.
If you can not set all the machines to a same directory or you expect your program to be installed in different machines, I would suggest you to create your own Temp directory, this way you would have full access to it. Just make sure, when you finish using y9our temp files to delete them
Tuesday, January 8, 2013 3:56 AM
Hi all,
The folder C:\TMPFIELS is available in the user's machine and have full read/write access. If it is not available the TMP folder should taken from GETENV("TEMP") in user's machine.(I suppose) But here the problem is that error messages indicate the TMP folder path of the machine where the application is developed.(Not the client's machine)
I create some temporary tables, save some templates etc for that TMP folder in my application.
Best regards
Tuesday, January 8, 2013 10:34 AM
What file is your application attempting to read from the "original" temp drive?
What command reports this bug?
If you app needs the invalid path then it means this path is stored in the project. Review the project file locations (open it by USE command and look inside).
Tuesday, January 8, 2013 10:54 AM
Seems to be a mapping issue, as I said before, if you can not go around do to all the different computers setting, I would suggest your application to set its own temp directory in each machine
You can also check the existence of a directory using DIRECTORY(<directory to evaluate>) and if you need to create one, you can do it MD(<new directory>)
Tuesday, January 8, 2013 6:15 PM
What you have in config.fpw during development is not changing what is used for TEMP on a target machine. You will have to either embed the config.fpw or execute the final EXE with parameter -c, by default an EXE will use system default folder for TEMP.
Even on your development machine some config.fpw file does not configure your VFP development settings, unless you load VFP9.EXE with that -C switch:
http://msdn.microsoft.com/en-us/library/80xwkkyx%28v=vs.80%29.aspx
Bye, Olaf.
Wednesday, January 9, 2013 6:08 AM
Hi Olaf,
I am afraid that I am not clear regarding above explaination. My EXE is build via VFP project (By clicking the 'build' button, recompiling and create the executable file). All .prg are included in the project.(Not .fxp files).I don't know how to build the final EXE with parameter -c in VFP project builder. Or how to embed the config.fpw to the EXE.
There is a Config.fpw file in the client's application folder to set the TMP folder path.
Best regards
Wednesday, January 9, 2013 11:44 AM
There is nothing to do at build. In your situation the config.fpw should be read, I guess your problem rather is your expectation about what files go into the path you specify as TEMPFILES in config.fpw. It's not everything going there. Also TEMPFILES does not change any system directory. Eg if your code uses GETENV("TMP") or GETENV("TEMP") you still write or read from those directories and not from the directory you specify in the config.fpw.
First of all you need to change nothing to let your app read the config.fpw you put beside it, you could include it in the EXE by adding it to the project manager (simply drag&drop) and set it to include, but that doesn't change anything.
You can check whether the external config.fpw file was found and read by checking SYS(2019)
If you want to change temp dir for cursors, you or your client should change the windows system environment variable TMP, it has precedence over the user variable TEMP and system variable TEMP. (See help topic Optimizing the Operating Environment).
Now what remains is Pavels question: What commands report this bug? When do you come across the error 'error reading files in C:\Docume~1\Machine1\Locals~1\Temp' and which files are being read there?
The second answer may be deducted from the first. So do you have an error handler telling you the location of the error? If not it's time to add error handling to your application to find out what code is causing this. That mostly answers the question.
Bye, Olaf.
Wednesday, January 9, 2013 8:33 PM
No TMPFILES setting in CONFIG.FPW is a good idea it just does not explain the 'error reading files in C:\Docume~1\Machine1\Locals~1\Temp path' on client computers.
This path must be hardcoded in the project somewhere and we are not able to help without sufficient response from Creative_Pro.
Friday, January 11, 2013 5:33 AM
Hello,
I am sorry for delay replying.
There is an error logging process in the application. Client reporting the error when loading some vfp forms in the application. And it throws vfp system error handler. i.e. Not running our error logging process. (I think this may happen because of environment settings in the client machine. And I think some files are unable to read/load and application is trying to quit.) The error message indicates that it is unable to read the quit.fxp (which is running when exit the application)
i.e 'error reading files in C:\Docume~1\Machine1\Locals~1\Temp\quit.fxp'
quit.prg is included in the EXE. But the problem is when this error happens it is trying to read the quit.fxp file in wrong path.(i.e. the path indicate the developer's default TMP folder path)
Best regards.
Friday, January 11, 2013 8:17 AM
OK, the path is really stored in the EXE and it contains the real folder of the quit.fxp file which is used during the project build. If the quit.fxp file is included in EXE then the path is not relevant and you may ignore it. Application should ignore it, as well...
The error could mean two things:
1) QUIT.PRG is "excluded" from the project - please check its status.
2) The EXE file is damaged somehow and the application cannot read quit.fxp when it needs it. You may compare the EXE where the problem occurs against the correct EXE.
I would recommend to append the QUIT.PRG file into your main PRG file (as PROCEDURE quit) and this way it will be available whenever needed.
Friday, January 11, 2013 10:30 AM
To avoid any complication I would also never call a function/procedure or prg or class or table or field or anything having a name with a reserved word. QUIT is a VFP command.
Indeed DO QUIT does not error with syntax error and does try to find either QUIT.PRG or QUIT.FXP to execute, so that's not the problem. Still a receommendation.
If quit.prg would not be included in compilation I wouldn't expect the "error reading file", but "file not found". So there seems something different is going on.
Do you distribute PRG files excluded from the EXE and then at runtime DO some.prg? If so, why don't you include them in your EXE? If you exclude the quit.prg and DO QUIT.PRG, the runtime will compile to QUIT.FXP and execute that file. The FXP is generated in the TMP dir. If that client has restricted temp dirs in some way that won't work and may result in the file read error. The error is not saying it can't find the file, but it can't read it, perhaps it can't execute it.
Perhaps you just need to get your project straight, include quit and anything you have in the EXE will execute. You will only need external files, if the files are subject to change or differ from client to client. EXECSCRIPT() would then also be applicable, but it will have the same problem with wrong temp folder confiugurations (in the sense of not allowing some operations in temp dir, not in the sense of wrong temp dir path). EXECSCRIPT also does generate an FXP in temp, but rather a _gjsf2se224.fxp like name (as generated by SYS(2015), not a name like quit.fxp.
Bye, Olaf.
Friday, January 11, 2013 11:33 AM
HI Olaf,
I am extreamly sorry to say that the .fxp file name is not exactly QUIT.FXP. I just want to give the idea that program is calling when the application quits. The name is dmQuit.fxp. Not Quit.fxp. And also dmQuit.prg is included in the EXE. And user has full access to the TMP folder in config.fpw file.
But not sure that the user has full access control for his Default temporary folder.
Best regards
Friday, January 11, 2013 1:26 PM
Well, nothing of that is addressing the error is saying it can't READ the file, not that it doesn't exist.
If all is well in the project, then a recompile and reinstall of the EXE is maybe the only thing you need.
Also the error is not explainable at all, if the dmQuit.fxp is included in the EXE, it wouldn't locate and read the file in a temp folder.
What does the project manager say is the location of dmQuit.prg? When you click on it in the project manager, what does the project manager window show in it's status bar as Path?
Bye, Olaf.
Friday, January 11, 2013 10:37 PM
I would not say the error isn't explainable. If the QUIT.PRG is included in the project then we are much closer...
Error reading file is low level error which can mean two things in this case:
1) The EXE is damaged
2) Some antivirus program is blocking the EXE file reading
So switch the antivirus off or create appropriate exceptions for it and/or compare the EXE against some surely correct one.
Nothing more, nothing else.
BTW, I don't know any FoxPro command except of ? and * which cannot be used as PRG file name. Even the !.PRG and &.PRG is correct program name.
Saturday, January 12, 2013 10:15 PM
>BTW, I don't know any FoxPro command except of ? and * which cannot be used as PRG file name. Even the !.PRG and &.PRG is correct program name.
The help topic on reserved words says "When programming, avoid using reserved words as names for window, table, or field names. If you use a reserved word as a name, it might generate a syntax error."
And I would extend that recommendation to any names. It's not technically needed, but is bad style to use reserved words for your own names. That recommendation is cautious and also tells no examples, where it applies, but what speaks against caution?
Bye, Olaf.
Sunday, January 13, 2013 1:53 AM | 1 vote
If "reserved words" would really be reserved then you may forget about the backward compatibility. The help is inaccurate in many other places and this topic seems to be prepared by absolute beginner.
Of course, you may write unreadable code when using command names as variable names etc. And some language elements are "reserved even more" than command names, e.g. system menu names but if XLS is on the list of reserved words what file extension should I use for Excel files?
Yes, you maight generate syntax error in some rare situations but such problem is immediatelly identified by the compiler and the number of mistakes is minimized.
But FoxPro language has other gotchas. Much more dangerous than reserved words usage is e.g. a number typed on a blank line by mistake...
So the help isn't dogma to me and I don't see any reason to implement all its recommendation word by word.
In fact I would like to fix this help topic.
Monday, January 14, 2013 5:52 PM | 1 vote
>if XLS is on the list of reserved words what file extension should I use for Excel files?
Well, you are allowed to write COPY TO "myexcel.xls" TYPE XLS, even though XLS is a reserved word, for the same reason you're allowed to write any command, because of course you need to write the reserved words in the places they are needed. And within a string you can write anything.
It's not a big restriction to not use reserved words, as you can always prefix them or add a suffix.
qmQUIT.prg is fine, for example. And yes, DO QUIT.PRG works, but I'd still see it as bad style.
Bye, Olaf.
Thursday, January 17, 2013 3:36 AM
Hi,
dmQuit.prg is included in the project. Not dmQuit.fxp. And the file path of dmQuit.prg is shown as the current folder where all the application files exists.(i.e. development folder)
Best regards
Thursday, January 17, 2013 7:48 AM | 1 vote
This is OK. The final EXE does not contain PRG file but compiled FXP file only. The compilation is done in your temporary folder during the EXE build so the temp path is also stored in EXE which is useless but also OK. The path from EXE should never be used because all necessary files are included in EXE and do not require any path...
But your observations say something else and your question isn't answered yet.
So are you able to create a small project containing just your dmQuit.PRG and some main program which will allow to simulate the behavior described in your question? Are you able to post your EXE for testing on our PCs?
Thursday, January 17, 2013 7:50 AM | 1 vote
OK, first:
While the project manager just lists PRG and VCX files, also FXP and VCT are part of the project and included in the final EXE through build. What executes in regard of PRGs are the FXP files, they are compiled PRGs. (The situation is different with VCX/VCT, VCT is a memo file including the compiled object code, that doesn't matter here, tough, as your problem is with a PRG/FXP)
So the part of your error message mentioning FXP is not at all unusual, if you Do qmquit.prg what is executes is qmquit.fxp. What is unusual about the error message is it points to the temp folder. If you DO dmquit the qmquit.fxp inside the EXE should execute.
So that will make this clear. FXPs are included with the EXE.
Second:
Since the qmquit.prg resides in the project folder, as the project manager displays it, that's also not the reason the error message points to the temp folder. If the project would have the prg included from that unusual folder, then this path would also be displayed at a target computer.
I can only assume at some point in your app there is a COPY FILE qmquit.fxp TO GETENV("TEMP"), then excuting that extracted fxp, or something similar. I wouldn't see any reasoning to do that, but I don't see another way this error results. GETENV("TEMP") or GETENV("TMP") stay the windows configured path, even if you set TEMPFILES via config.fpw (as I already said), this is the part of the reasoning, that you can still have the windows users temp folder involved, even though you set TMPFILES to C:\TMPFILES.
If you know at least how you can cause this error, eg by quitting the app or clicking a button,, the way to find out this is debugging. I wouldn't search the project for such a COPY FILE line, there are gazillion other ways to do this, but I see no other way than code extracting dmquit.fxp causing this. VFP does not put code into TEMP, neither your TMPFILES nor Windows Temop, the only fxps it puts there is the fxps created on the fly when you call EXECSCRIPT(), but these file names look random, like SYS(2015), never something like dmquit.fxp.
So debug by starting with a breakpoint at a location like the click event of that button cauing that error, then you'll get to the code doing this.
Searches with the Code REferences Tool, which would be good to do, obviously are searching for dmquit, to find any code doing anything with dmquit, or GETENV, to find any code retrieving system environment variables, but debugging should be the shortest path to finding out where dmquit is put into temp and executed.
Bye, Olaf.
Friday, January 18, 2013 8:48 AM
Hi experts, just build an exe then open PJX file as a table, Object field stores a temporary path and the file name for all files in the project.
i.e: C:\DOCUME~1\UserName]\LOCALS~1\TEMP\PrgName.fxp
[UserName] – Exe built user’s name
Actually there is no fxp in that location. Don’t know why does this happen.
Somehow exe tries to find this file and gives
Error reading file C:\DOCUME~1\UserName]\LOCALS~1\TEMP\PrgName.fxp
This is not a problem in the coding I guess.
Friday, January 18, 2013 10:30 AM
VFP uses that path for temporary files storage during the project build. You may see it in process monitor.
To explain why VFP reports an error when reading the file needs further investigations - at least I am still not able to reproduce this bug in my environment.
SMB2 is not involved in local disk file access.
Friday, January 18, 2013 11:46 AM
No where it's mentioned the EXE location, may be in a server path.
Friday, January 18, 2013 12:40 PM
If the error occurs when the EXE is executed from a server location then you should test it when running on a local drive. Your network environment could affect the EXE reading and Error reading file is possible in such case.
Friday, January 18, 2013 1:41 PM
Yes, I see the same in my PJXs, but it will not lead to that error, even if I put my EXE to a network share and run it from there. So as Pavel said this isn't unusual for the build process.
I think we're back to a build problem with your EXE or VFP. You could try to uninstall and reinstall VFP and see if the EXE built with the newly installed VFP works correctly.
Bye, Olaf.
Friday, January 18, 2013 2:02 PM
Are you trying to write to the Temp directory on purpose?
In my experience, if you call an executable, unless you specify on the EXE to set a default directory, it will start from the temp directory
Friday, January 18, 2013 2:16 PM | 1 vote
The default/current path when you start a VFP exe always will be the EXE path. But that's not the problem here, Benny. Pavel has identified it: VFP's build process creates the FXPs of the PRGs inside TEMP folder (even though afterwards the FXPs are put besides the PRGs into the project folder, too). And that path is put into the PJX and the PJX is included in the final EXE.
The problem arises at the client using the EXE, which makes me think the PJX made it into the final EXE, but the FXP is missing in it, so VFP errors not finding the FXP.
Just about one-two months ago I had a similar weird buiild problem with VFP. It would compile an EXE just 750KB from a project normally resulting in a 7.5 MB EXE. It's not the factor that matters, but running the EXE did look for a prg via OPEN FILE dialog. In my case even the main.prg was missing from the EXE (I assume). So such build problems can exist, EXE is incomplete.
In my case using e replacement HDD helped, having a fresh image of a last image backup. So it was really VFP itself having become corrupted.
Bye, Olaf.
Wednesday, June 27, 2018 1:52 PM
Using the default windows temp folder seems to not work very well when with applications being run through RDP sessions.
Foxpro seems to do much better when the TEMP folder is set to the same drive as where the database and table are. The incidence of random "Alias not Found" errors was drastically reduced by setting the temp folders in the config.fpw file to the same drive as the database.
Wednesday, June 27, 2018 3:01 PM
First thanks for reporting that. I can't see a good explanation why this would be the case, unless the default TEMP folder location configured in Windows would be unideal.
Reading and writing on different drives, albeit all local drives, should help, so DB on a local D: drive and TEMP on a local C: drive would help, unless C: is much slower than D:, eg one is a SSD the other not.
The same drive theory is not a good explanation anyway, especially if you have comparable speed separate drives.
There's another aspect in that multiple sessions each run in separate subfolder of a main TEMP folder. If your application configures a single folder that may give you an advantage, if your application puts some standard data into TEMP it uses and then uses for all users in shared mode instead of needing a copy for each user, but that mechanism wouldn't be normal, you normally only have cursors in TEMP and even only get physical files when their size goes over the threshold given by memory allocation. So temp files rarley get created anyway and in case they do, they have random names, simply look into DBF("cursor") and FILE(DBF("cursor")).
Cursors written out to temp point out your Terminal Server has too low resources and every user session becomes too small.
Bye, Olaf.
Olaf Doschke - https://www.doschke.name
Wednesday, June 27, 2018 9:15 PM
Using the default windows temp folder seems to not work very well when with applications being run through RDP sessions.
Foxpro seems to do much better when the TEMP folder is set to the same drive as where the database and table are. The incidence of random "Alias not Found" errors was drastically reduced by setting the temp folders in the config.fpw file to the same drive as the database.
I would guess the database is somewhere in the shared folder whereas temp folder is in the space used by one user only. "Alias not found" errors must have some reason to raise. And it should not be the TEMP folder location. "Alias not found" means the previously open file is closed now. Additional reason could be unattended Data session change. Can you imagine some process closing your files located in TEMP folder? Do you use Data sessions?
VFP handles file access independently on the file location. Why would VFP close the open table when it is located on the C: drive but not on the X? Did you try to log these errors? What file types were the disappearing aliases used for? I mean tables or cursors created one of the possible ways.
The only result for me: Your RDP environment does not seem to be reliable. What RDP do you use? In what environment?
We are using Windows Server 2012 as TS on IBM Softlayer cloud virtual (most likely) machine and no such problems occur. The only visible problem is slow speed on folders mapped as drives - original disk is about 5 times faster.