another multi-user "solution"?

[Rob Cozens]

Hi Kurt,

>I know that there are probably those for whom working with SQL is a piece 
>of cake; in their eyes I'm probably making things much more difficult for 
>myself that they need be....

A project I was working on started down the SQL road and hit a BIG bump 
with the first book on actually setting up and administering an SQL network 
on Mac OS X.  Do you like Unix command line syntax, aka Apple's Terminal 
application?  Would you like to walk users through it over the phone as 
part of your support effort? Do you want to predefine every data field to 
the database...and assign each a data type which may be meaningless to 
Transcript?  Do you want to ship &/or install different versions of server 
on different platforms?  Then yes, you may be making life more difficult.

Kurt, I was going to suggest you look at working within Transcript's record 
locking procedure; but I recall doing that in the aftermath of learning the 
realities of SQL.  I concluded that, since Transcript reserves write 
capability for the first person to open a stack until she closes it, any 
scheme that requires concurrent update by more than one user meant opening 
and closing the data stack with each read or write--which I considered 
unacceptable overhead.  But note that all read-only stacks can be shared by 
multiple users now.

What you propose with text file databases should work seamlessly within 
Transcript and require no third-party software.

...and if that fails, there's always SDB.     :{`)

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)