>>>Hi,
>>>
>>>I am wondering if it is a better practice to have the class defined in a PRG file or VCX file? Note that I don't care about the speed. All I care is about how VFP uses the class. Let me explain what I mean by "uses" (because I don't know how).
>>>
>>>In my application there is a class PASSWORD defined in a PRG file. It has several methods and a number of properties. This class is instantiated at the top of the application and the reference is a PUBLIC variable oPassword. Again, it is not important that this is a public variable. I can easily make it into a property of the application object/class. But I think, at this point, it is not important.
>>>
>>>This class PASSWORD works for 99% of the customers without any problems. But I have a customer (I already have a couple of threads about issues the application has there) that has the following problem.
>>>
>>>Sometimes (rare but sometimes) when a method of the class PASSWORD is used (e.g. oPassword.passcode( ### ), the program bombs with the message "cannot find the file c:\users\.......\password.fxp"
>>>Interesting that at exactly the same time the application loses connection to the SQL Server (because I keep a log of these issues). But using the code suggested by Walter Meester, the SQL Server connection is restored ON THE FIRST trial. Which is great. But I don't know how to restore the application connection to the VM share where the application reside. Therefore, I have two questions:
>>>
>>>1. If the class PASSWORD is refactored into a VCX file, do you think it will be more stable?
>>>2. My understanding is that the entire application (it is about 17MB in size) is loaded into the PC memory when the application starts. Therefore, the application should not really "go back" to the VM share to get some code. Because the code is all inside the APPL.EXE file and therefore in the memory of the PC.
>>>What then "wipes" the code from the PC memory that the application needs to "go back" to the share?
>>>
>>>TIA.
>>
>>I have had the same problem at a client, and also was wondering, why the exe requires constant access to its source, although it is somehow loaded in memory.
>>To be able to "restore" a network disconnect of such sort, the only solution I could imagine is, that you load all program files into a temporary folder during start up, so making the files available on the local PC.
>>I could imagine a strategy like the following:
>>

>>LOCAL lcTempFolder
>>lcTempFolder = FORCEPATH("myAppFiles", GETENV("TEMP"))
>>IF ! DIRECTORY(m.lcTempFolder, .T.)
>>	MKDIR (m.lcTempFolder)
>>ENDIF
>>
>>*-- ExeFilesList is a list of all project files.
>>*-- Since I don't have a way to get this list dynamically from the executable,
>>*-- it is created during building the executable. Note that all files must be included, like vcx/vct, frx/frt etc.
>>FOR EACH lcFile IN ExeFilesList
>>	ERASE (FORCEPATH(m.lcFile, m.lcTempFolder))
>>	STRTOFILE(FILETOSTR(lcFile), FORCEPATH(m.lcFile, m.lcTempFolder))
>>ENDFOR
>>
>>SET PATH TO (m.lcTempFolder) ADDITIVE
>>

>
>Thank you so much for your input!

You are welcome. I forgot to mention that I did not implement this code, and I also did not test it. So worst case scenario, the process still searches for the resource on the original executable location and having a copy of the same file in the path does not avoid the error message.