Stack file size

[Rob Cozens]

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)