>>>Hi everybody,
>>>
>>>There are couple of internal VFP things, which lead me to some frustration and problems with new versions.
>>>
>>>First problem is: When application (.app) executes on user's machine, it automatically resides in memory, so there is no way to update this application, without kicking everybody out. I know about different "launcher" approaches, but we haven't implemented any of them so far, so this is still a real problem for me (and my colleagues) as developers.
>>
>>I believe the best approach is to use a launcher. This gives you two HUGE advantages: 1) Your problem above is solved. You don't have to kick everybody out. 2) Users can go back to previous versions of your executable. Very useful is the latest update has unexpected side-effects.
>>
>>Code available on request.
>>
>>HTH, Hilmar.
>
>What if application change also involves adding/changing some tables (and their structure)?
>

What we used to do (where I previously worked) was, at the beginning of the code, have it check for something in the database that would be new since the last update. If it is not there, then run some extra code (like in a db_fix.prg), that would go in and update the database to the new level you need.

Next time it runs, it would ignore this, and skip it.

But you have to keep db_fix updated with any new changes to the database (must be in sync or all $#!!#!#$#$ breaks loose!!

Tommy

>BTW, how about the second problem?

Yikes!!! My poor little brain can only handle so much, 'Cap'n......