Thomas- Thursday, March 13, 2003, 4:52:10 PM, you wrote:
TF> If two users are writing to a file at the same time, it *will* cause TF> problems. I don't understand what you mean by locking "properly": a TF> file is locked or not. Depending on the programming language, you TF> might be able to distinguish between "lock only if accessing for TF> write", or you have to lock the file completely, disallowing all TF> access by other users while one user is accessing it. At the "same time", yes. Anyway, my bad - I should have said "locking" instead of "file-locking". It's entirely acceptable and preferable in a database application to lock records rather than the entire file, thus allowing multi-user writes. In TB's case this might be allowed by locking an individual message, writing the "deleted" bit, and then unlocking the message. I have no idea whether or not this is the way it is implemented, not having that kind of an in with the developers. TF> network. I prefer to lock them completely rather than for write access TF> only. Mind you, if someone opens a file, it will be open for less than TF> a second (to be vague), because once the data is in his RAM, the file TF> will be closed again while he still sees it on his screen as long as TF> he wants. Hmmm. I never lock files on reads. Maybe I should revisit this some time. It's a good point, just to be safe. TF> No, I am thinking of software engineering stuff, in this case file TF> access and BIOS. Want to talk with me about semaphores and how file TF> locking works? Or what physically happens when a file on a network TF> drive is accessed for writing by two users at the same time and why TF> this *will* (not *could*) cause data corruption? I've got a multiuser MSAccess database for a nonprofit I work with that supports simultaneous writes by multiple users into a single backend database. Mind you, MSAccess has its own quaint way of defining record-locking (sheesh - don't get me started on Access and semaphores or we'll find trout flying), but I do take issue with the above. TF> I wasn't just babbling about, I studied this stuff (got a postgraduate TF> diploma in Computing - reminds me, I have to register for my master's TF> thesis within this month). I have also been programming since 1978, TF> and that includes writing applications running on LANs. My condolences on having had to put up with an entire CS master's program <grin>. I can usually rely on your expertise in your postings, which is why your blanket generalization above got under my skin. No, you weren't babbling, but it's simply not true (and misleading in terms of the original question) that simultaneous file accesses *will* cause "loss of data integrity, corruption, or loss of data". The client-server multiuser capabilities of TB are what won me over in the first place and the main reason I work on convincing my clients to give it a try. Well, it also helps that I tell them I won't support Outlook... -Mark Wieder Using The Bat! v1.63 Beta/7 on Windows 2000 5.0 Build 2195 Service Pack 2 -- ________________________________________________ Current version is 1.62 | "Using TBUDL" information: http://www.silverstones.com/thebat/TBUDLInfo.html
