>>Yes-- a self-updating executable is very near on the development schedule. There are numerous ways I can conceive doing this-- how do you go about it?

> Our main exe checks for the existence of a file on the local machine and the network (just a text file with a timestamp in it). If the file exists, the file date/time is checked to see if it the files are the same.

> If the files are not the same, or one or the other does not exist, the main exe copies the 'copy' program from the server to the local machine (this ensures that file is updated). Then the 'copy' program runs and compares the files in several directories to the master copy on the server - if they do not match, the files are brought down to the local drive. We can delete the text file on the server or the local machine to update all clients or just the one we are on.
>
> We also delete files and directories that are not part of our application - ones that someone has placed there by mistake. We tell our clients this, and for the most part they stay out of that area.

How about updating the main EXE on the workstation. Using the copy command directly from it would give sharing violations. What I was considering, is having my primary EXE, when started, test time-stamps on all files possibly needing to be updated(including itself), comparing them to the ones on the server. If any were out-dated, it would first copy an update executable from the server, and then execute it with ! /N(so it doesn't wait), immediately followed by a QUIT(unlocking the EXE). This executable would copy over the most recent files from the server(not just the ones that need to be done-- I'd rather be thorough), register any OCX files, etc. that should be registered, and then re-launch the main program. Sound good?