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