Rick,

Thank you very much for your detailed answer. I just looked into my project which has your product and see that all your classes are in .PRG files.
Now I understand why (the technical term "pain in the ass to deal with" explains it :)

>VCX class libraries are automatically loaded into memory when an APP/EXE runs so there's no explicit need to SET CLASSLIB TO for example. That can be more reliable than PRG files, if you're not tidy with PRG file inclusions.
>
>PRG/FXP files have to be explicitly loaded. If the PRG is compiled into the project it will be found based on the 'included' file reference loaded from the project before looking in the file system. If for some reason the file is not compiled into the project you can get the file not found errors if the source file on disk also can't be found. If that's the case I suspect there's a problem in your application where somewhere perhaps an errant `SET PROCEDURE TO` without an `ADDITIVE` clears the loaded procedure file stack? Perhaps an error routine?
>
>If this happens during debugging, the problem is often that the PRG and FXP file are out of sync in which case the debugger can't step through the code because it can't line up the compile FXP code to the source PRG code. But this shouldn't be an issue just running the app unless the PRG is not actually loaded. The thing to do when this fails is to look at the `SET("PROCEDURE")` and see what's actually loaded - you'll likely find that the file in question is not loaded.
>
>The other issue is to **make sure** that your PRG files are actually part of the EXE file. When you run your application locally it may not always be obvious that you might be missing a PRG file inclusion in your project but the file can be locally loaded. In production then the file might not be present and cause an error. This should be rare but can happen if PRG files are loaded dynamically via macro or `eval()` in a way that the FoxPro compiler can't automatically pick up the file when it walks the compilation dependency tree.
>
>Personally I tend to explicitly load all my dependencies either on startup, or via library loader headers on an PRG library that does `SET PROCEDURE` `SET CLASSLIB` for all of its dependencies which ensures that everything needed gets loaded. It'll also ensure that the VFP compiler picks up all dependencies and includes them in the project.
>
>I try to avoid any VCX/SCX classes whenever possible because they are a pain in the ass to deal with with source control and you have to edit them through the IDE (a lot of clicks or the messy lengthy MODI CLASS syntax) which is annoying as heck. You also can't use an external editor for VCX/SCX code. For me the only place I use VCX/SCX classes anymore is for things that more or less require it which is mostly UI components or ActiveX related bits. For everything else - always code.
>
>Functionally VCX and PRG classes are the same once loaded. They translate into the same code structures so the difference really boils down to the storage and loading mechanisms of classes.
>
>+++ Rick ---
>>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.