run Rev app on two networked computers?

[Rob Cozens]

Hi Kurt,

Without knowing how the data will be used, I can only offer general 
suggestions:

>I have read the entry "How to...allow multiple users to access a 
>stack on a server", which seems to be a recipe for avoiding the 
>stack collision mentioned earlier.

* The recipe for avoiding stack collision mentioned in "How to ..." 
works by restricting access to the database to the first user to open 
it and not allowing other users to open it until the first user is 
finished and the temporary file is deleted.  This still leaves one in 
"single user" access mode.  IF you want more than one user to be able 
to open & update a database stack "simultaneously", that recipe won't 
do the job.

This is why I prefer a client/server approach: there can be NO data 
collisions because only the server application modifies the data 
stack.

BTAIM (Be That As It May), here is the recipe used by the Flexware 
B-tree database I worked with for two decades:

1.  Create ONE control file shared by all apps using the data stack.

2.  Before writing to the db, a standalone reads the contents of the 
control file.

     A.  If the control file contains another users' id, the 
standalone returns a DB Busy error or waits some specified time 
interval and reads the control file again until the control file is 
empty or the maximum number of retries occurs.

     B.  If the control file is empty, the standalone writes its user 
id to the control file AND then reads the control file again to make 
sure no other user gained control between checking the control file & 
updating it.  (Flexware's designer insisted rereading the control 
file is essential.)

     C.  Once the control file contains the standalone's user id, the 
db write takes place and then the standalone (or write command logic) 
empties the control file.

Note that neither the Rev recipe nor the above deals with record 
locking (Flexware handles this by physically flagging locked 
records...which means locks persist between runtime sessions.  SDB 
server maintains a table of locked records in RAM; so locks disappear 
at server shutdown.)

>Do I need to study the SQL section

If you wish to use an SQL server, yes; otherwise no.  If you're 
working with Mac OS, be prepared to learn the Terminal application 
and Unix command-line syntax.

>Would it be practical to write to a text file as a database?  I 
>visualize the data as being  <1000 rows, and < 10 columns.

If your application has a finite database, this should work fairly 
well.  You might then try loading the entire db into an array.  If 
your application db does not have a fixed structure, uses keyed 
access, &/or supports multiple record types, this becomes more 
problematical.

Rosli,

>   open file x for append --so old data wont be deleted
>   write myData to file x
>   close file x

* Suppose one is updating an existing record rather than adding a new record?

* Suppose records reside in the file in key order rather than order 
of creation?

Chipp,

>because if both apps try and write at the same time, it will throw 
>an error as the file is locked when opened in an append for write 
>mode

I'm not sure this is the case; but I have not tested it.  In any 
case, one would then have to open the db before each access and close 
it afterward to keep from locking out other users.

Andre,

>by the way SDB is amazing... I really like it.

Thanks for the kind words.  You ain't seen nothin' yet.  Once I have 
finished the keyboard filtering frontScripts, SDB will be, IMFO, WAY 
RAD.  I have my test stack built & scripted; but other issues have 
caused me to delay testing.
-- 

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)