Hi John,
I'm a hobbyist - I script when I have to! But even for people
like me, there's a need to face up to the real world - separating program
from data is what databases are for, and that why the grown-ups use them
Before HyperTalk, essentially all databases housed data separately from the
applications that use them.
There are advantages to this arrangement, including elimination of the
posibility of disassociating the data & application logic; but there are
several disadvantages as well:
* Difficulty updating program logic (as you noted)
* Duplication of program logic in multiple databases (eg:
maintainng multiple address stacks)
Also, there are other reasons for using a database besides separating data
from program logic:
* Accessing individual records by key value
* Faster retrieval of individual records
* Multiple index paths to the same data
* Facilitate retrieval of data based on ad hoc queries (the "Q" in
"SQL")
though in the case of the Address stack, these considerations are generally
non sequitur. (OTOH, one could build indexes to access Addresses by zip
code, state, etc. with an indexed database.)
So back to your update issue.
As others have mentioned, your new stack [but not a standalone app] can
load data from a text file of data extracted from the old Address stack.
So long as you are working with a stack, you could experiment with creating
an updater application that installs modfied scripts & new controls. I had
this approach working well with HyperCard stacks, and could add virtually
any changes to existing stacks. But it doesn't work for standalones.
If you simply want to support the functionality of the Address stack in
single-user mode, you don't need:
a relational database or client/server architecture
ad hoc query support (though you need a replacement for "Find")
a data dictionary
IMFO, SDB is well suited as a database supporting the Address stack
application.
SDB is written in native Transcript, so one version runs on all
platforms. It includes RAD tools to:
* create a database front end stack from an existing Revolution stack
* create a database front end stack from the (optional} data
dictionary in an SDB database
* create a data dictionary in in the database stack from an
existing Revolution stack (optional)
* load data from a Revolution stack into an SDB database
An SDB database is a Revolution stack, and is therefore accessable via Rev
development tools (db utilities are also included). SDB is free of charge
and 100% open source: <http://wecode.org/serendipity/>
Rob Cozens CCW
Serendipity Software Company
"And I, which was two fooles, do so grow three;
Who are a little wise, the best fooles bee."
from "The Triple Foole" by John Donne (1572-1631)
_______________________________________________
use-revolution mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/use-revolution
