Communicating between to standalones with "write to process" - Found word(s) list error in the Text body

[Dr. Hawkins]

On Tue, Dec 3, 2013 at 9:47 AM, Mike Kerner <MikeKerner at roadrunner.com>wrote:

> As far as the vocabulary, no, sorry, that's from [a number greater than
> what I'm going to admit] years of working in the DB space on lots of
> platforms and on lots of very interesting problems.
>

save us from dull problems :)

>
> The reason for using the server is that it takes most of the work out for
> you, and you just worry about talking to it.  Transactions, triggers,
> semaphores, record locking, etc. can all be handled that way.  Now once you
> get into multi-stage commits, you and I have to talk because that's a topic
> that is generally beyond the scope here.
>

I doubt that this will ever need that.  I'm just sharing a few hundred
variables and a couple dozen to couple hundred still fairly simple records
(simple enough that I can store their INSERT statements


> You could, if your data set was not abhorently large, also use LC's fields
> as your database, and go old school with creating a card for each record,
> etc.
>

:)

That's the original 1989 version of this program . . . I switched from
HyperCard to SuperCard so that I could have a single stack rather than two
stacks per client . . . but it's hard to simultaneously access such a stack
from multiple offices.  I'm using the in-memory SQLite not because the data
is so complicated (I had it in an array for a while, too), but because
SELECT/WHERE and ORDER BY do so much of my work for me.  Oh, and SUM() is a
huge help, too.

In '89, we were just tickled that I could process a card with a debt or
asset on it about once every second . . . sticking it into an appropriate
output form.  I could have converted it to HyperCard 2 when that came out,
but that would have meant copying every script and pasting . . . (I suppose
I could have written a script to disassemble, and another to assemble, but
. . .)



> Then if you communicate with the stack, you're really just
> communicating with a "crude" database server.
>
>



-- 
Dr. Richard E. Hawkins, Esq.
(702) 508-8462