Updating Data Substacks

David Vaughan drvaughan55 at mac.com
Fri Jul 12 03:58:01 CDT 2002


On Friday, July 12, 2002, at 04:36 , Ro Nagey wrote:

> Another approach that I implemented on a POS WAN back in the 
> pre-Internet
> days:
>
> Ship the new stack[s] under a new name. On startup, it checks to see 
> what
> it's name is...if it isn't MyOldStackName then it reads the data from 
> the
> old stack[s] into the new stack[s], changes the name of the old stacks, 
> then
> changes the name of the current stack to MyOldStackName.
>
> That way, you're previous rev is still there in case something goes
> tragically wrong.

This is a good option, and I like the hidden data stack as well. A 
logical counterpart to Ro's suggestion (and which I have used in HC but 
not tested in Rev, although I believe it should work) is to ship a 
code/UI updater rather than either a replacement stack or a data mover. 
This enables you to keep data in the (non-splash) stack structure and 
simply modify the controls and scripts. It really depends which is more 
complex and risky, moving and modifying the data or modifying the 
controls. Changes to field/data structures has implications for any of 
the models suggested.

regards
David
>
> Ro
>
>> -----Original Message-----
>> From: use-revolution-admin at lists.runrev.com
>> [mailto:use-revolution-admin at lists.runrev.com]On Behalf Of Dan Shafer
>> Sent: Thursday, July 11, 2002 7:07 PM
>> To: use-revolution at lists.runrev.com
>> Subject: Updating Data Substacks
>>
>>
>> It just occurred to me that the RR model which requires me to create
>> a separate stack to hold the data for my app might be an obstacle to
>> product upgrades.
>>
>> My mainstack is a splasher. My substacks are a palette (which can
>> change) and the primary data stack (which will change). If in my next
>> rev of the product, I wish to add features (e.g., a menu or even a
>> button on that stack with some new functions), I would expect to ask
>> my users to replace their current stack with the new one. But that
>> will, obviously, result in the loss of all their data.
>>
>> How should this work? What am I missing?
>> --
>> -.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-
>> Dan Shafer
>> Technology Visionary - Technology Assessment - Documentation
>> "Looking at technology from every angle"
>> http://www.danshafer.com
>> 831-392-1127 Voice - 831-401-2531 Fax
>> _______________________________________________
>> use-revolution mailing list
>> use-revolution at lists.runrev.com
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>
> _______________________________________________
> use-revolution mailing list
> use-revolution at lists.runrev.com
> http://lists.runrev.com/mailman/listinfo/use-revolution
>




More information about the use-livecode mailing list