>Hi Ed.
>
>I use a similar approach (although your's sounds way fancier!).
>
>>It also means that application updates will roll themselves out as machines log in automatically.
>
>Another, related, advantage is installing updates. If the app is run off the server, you can only install an updated version when everyone is out of the application. With local copies, you simply install the new version on the server and each users gets the new version the next time they run the launcher. Of course, you can't apply data changes this way, but for app-only changes, it's way better than trying to kick everyone out or installing after hours.
>
>Doug

I do the same thing. With data updates, it is just as easy using SDT. On the server I have a directory called AppUpdts for the app updates which my launcher brings in automatically. I also have another folder called DBCUpdts. I put a zipped file in this folder, database.zip. My launcher looks for the existence of this file, and, if found, notifies the user every time the app is launched until it is processed.

I first test to see if I can open a globally used file exclusively. If so, I know no one else is in the app. During the processing I unzip the file usually to getenv('TEMP'). I include a table that lists the contents of the zip file and the folder to copy the files into. To finish the process, I call my DBC_Validate procedure which calls the SDT validate method if needed.

My directory tree on the server for all apps looks like:

apps\app_name
apps\app_name\database
apps\app_name\reports
apps\app_name\appupdts
apps\app_name\dbcupdts