Just an idea, not disagreeing with what you've decided, but just an idea:

If you want to make the "other than first" install faster on the 1.44 floppy method, you could write a little batch file (update.bat?) that self-extracts the EXE to the proper spot on the hard drive. Then it is a (probably) one disk update instead of a full-blown install.

Joe

>>>When a table is added to a DBC it is linked with a unique id. One cannot overwrite an old table with a new one by the same name because the ids won't match and the DBC will complain.
>>>Question: What is the best method to update an EXE of an previously installed app without overwriting the old data tables (hence, the data)?
>>
>>I put my non-data application files in a subdirectory of my development tree called "PROD" (production). I then create my setup files starting in this directory. This prevents any inclusion of data files. I can also mimick my application tree under this subdirectory if needed.
>
>Thanks Mark, and the others who contributed! (UT is the best support system in existance!)
>This sounds like the approach I want to take. Copying the EXE will work only when users are accessing from a network installed app, which is a method I already use. But, some users will be installing the app onto standalones using the DISK144 method, and I am not comfortable with them dragging the EXE from a floppy if they didn't do the normal install. The idea about using the ALTER TABLE command in a preinstall EXE sounds neat too!
>
>Jerry