>Hi Hilmar,
>
>>Putting it on the server will make program start slower, as you have been told in other replies. I believe this is not significant. Once the program is loaded, it is in RAM, and there should be no speed difference. But just in case, make your own speed tests.
>
>I am not sure a vfp.exe is loaded totally into RAM. The "exe" part AFAIK (to be honest, I haven't done any relevant research or testing here) is just a stub loader to load the runtimes (if not called from a running vfp/vfp.exe. I don't believe everything in the .app / .exe is loaded into RAM, since that would defeat the purpose of adding large tables (for instance in insurance apps) into the apps. I am certain, that in older versions the RAM needed after acessing an App with more than 10MB of tabular data didn't grow that much. I believe that there is some kind of overlay scheme working or (more probable) that the app-file is handled like another table or virtual file system.
>
>***When*** it crosses the network might even be a separate issue.
>
>The way to test this would be to include a 400 MB table into the exe and start it, sniffing the net and watching the memory used for the app. Repeatedly accessing such an included monster table might create a performance issue...
>
>Have *you* tested the behaviour of vfp.exe's or are you also arguing from common sense ?
>
>You know, I am always curious about more data of the fox' inner workings...

I would be very surprised if VFP wasn't discerning enough to load the entire EXE except for embedded tables which would be loaded a bit at a time as needed similar to non-embedded tables.