Communicating between to standalones with "write to process" - Found word(s) list error in the Text body
dochawk at gmail.com
Sat Dec 7 16:06:44 EST 2013
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,
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.
More information about the Use-livecode