Hi Alan, A> I'm making a small "Phonebook" type data base program that I want to access A> from several computers on a local net and maybe remotely. I was originally A> going to use a text file to store the data but I'm thinking that there is a A> possibility that it might be accessed by two different people at the same A> time. Without going with a MySQL database what methods can I use to insure A> that simultaneous access will not screw up the data base file.
There is no definitive solution for this, aside from using a real database; there are various techniques you can use though. 1) Create a "lock" file when you access the database. The first thing you do is check for its existence, create it if not there, and delete it when you're done. You can't access the DB unless you're the one who created the lock file. A spin on this approach, depending on your needs and desires, is to store actual lock data in the file, so you can lock specific records, etc. Of course, this can just push the same problem over to the lock file rather than the DB. 2) Use the WinAPI (or other lib access) to "lock" part or all of the file. If you can't acquire the lock, you can't do the work. 3) Check if the DB file exists, if so, rename it (so others won't find it). When you're done, rename it back. Doesn't work if you want to auto-create the file of course. 4) Use the file system as your DB, storing one record per file. Works well for small-scale apps. From there, you can build what you want as far as extra protection, locking, versioning, etc. Bazillions of systems use this approach these days. None of these are perfect solutions. A> Is this a thing for which "rebol services" would be useful? Yes and no. If you write a DB server that serializes requests, handles lock contention, and all the rest of the stuff a real database does, it would be very robust. At some point, a real DB makes sense. There are lighter-weight DBs than MySQL as well. What is the risk, what is the worst that can happen, etc. Don't build a solution, or a file format, that is easily corrupted; and make sure it can be rebuilt without too much difficulty; that's the main thing to keep in mind if you're building your own system. -- Gregg -- To unsubscribe from the list, just send an email to lists at rebol.com with unsubscribe as the subject.
