>>We use a one-time build of a one-program-only startup PRG (hence EXE), just calling the individual FXP's ... ehh, EXEs. Obviously the DLL's etc. are in the build as well.
>
>OIC. I think you do mean you call the individual FXPs. One advantage of doing this is it's easy to upgrade a single piece without everyone having to log out of the entire system. Another option, assuming your system can be easily separated into modules, is you can compile a number of the PRGs into a single APP, which is called from your EXE. You may also want to look at combining sets of these PRGs into several procedure files, based on function.

Barbara,

Of course, various options exist. But I really don't have the need and it's a bit of the contrary : working like this is much, much easier. When someone has a prob in some function, we adjust that by the minute, and send it the other. It saves about 100 % of the time needed otherwise. Furthermore, our ERP allows for continues incremental upgrades (rather unique btw). The developer doesn't even know about "upgrades" as such, and no other instance does. It just needs the bunch of functions to declare "ready" formally, and some system does the rest. This system knows per customer what the status of his system is, and the user just downloads (Internet) "an" upgrade. Nobody here interferes. On average upgrades are drawn once per 1 - 2 months, but it just as well could be each other day. We won't notice.

The only PROC we have is the bunch of "system programs", which is physically as large as our complete financial subsystem.
And obviously we have the bunch of classes. This is just about the GUI and all the control in there. It doesn't have any business rules in it (that's in the PRG's mentioned).

So again, it's a kind of other way around : it took some investigation from off VFP 3.0 (FPD 2.0 also) on how to achieve this, where all urged for an .APP at least ...