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)
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
