>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?

Let's take a look at this from another perspective: consider the OSI model https://en.wikipedia.org/wiki/OSI_model . Each layer of that model relies on lower-numbered layers to function. You have a user-facing app (Layer 7). At one customer you are experiencing network disconnects in both NetBIOS (access to your EXE on a remote share) and SQL Server, so I suspect there's an issue in that environment in Layer 4 or lower.

You have several options:

1. Make your app fault-tolerant. One example is the retry function you're using for the SQL Server connection. This can be useful for some types of transient issues but cannot work if an issue persists, so no guarantees are possible

2. Change the operational requirements for your app. For example, if you run your EXE from a local drive, it will not need a network connection to access its components. This approach can reliably address some issues

3. Fix the underlying network issue(s)

Option 3 is by far the best. It addresses the root cause rather than symptoms. If you continue to have persistent issues at lower levels in the software stack you end up playing Whack-a-Mole in your app with transient/intermittent issues or edge cases, just like you're seeing with this customer. Implementing options 1 or 2 can be expensive. If it were me I'd make it clear that any changes made to try to accommodate environment issues at one particular customer would be charged back in full to them. That often gets management to light a fire under their sysadmins to get it fixed.

Re loading of a VFP EXE into memory: I can't recall anyone running a VFP app in a debugger to confirm what actually happens in this sort of scenario. Your understanding may be correct, but the types of errors you've been seeing implies the opposite.

This PRG vs VCX question is part of option 1 (fault tolerance). In view of the other issues you're seeing I recommend refocusing your efforts on getting that customer to address the problems with their environment.