On 9/7/06, Claude Schneegans <[EMAIL PROTECTED]> wrote: > >>it's easier to treat every update as an insert, and just keep a > history of who's done what when, and what was there before. > > Easier? This is just a patch to eventually fix problems by hand when > they appear, > PROVIDED someone finds it, not really a method to PREVENT problems from > happening.
Well, it prevents it from being a problem. You never have a race condition. At least not one that you can't look back on and KNOW who won-- Or even revise and tweak the results... I mean, HTTP is what it is, and sure CF and whatnot can make it seem pretty stateful... but I wouldn't want my heart surgeon to work on me remotely via it. But what are you thinking? Where'd you use row level locking? A r3al life example? Personally, I'd rather be able to do whatever I want to do, whenever I want to do it, and let some other process decide what should go where when. There's no reason for me to wait around... maybe a little "stan is working on this too" type message, but no lock. The connection isn't that cool for that-- and so you're looking at software-- so why not do it in CF anyways and be done with it, forever, nixing the weak link of the "sometimes there" web? DB's aren't web servers... but, then again. What are db's? There are "Object" databases now... tons of specialized ones... I guess part of the problem is having to connect from various sources-- some more programmatical, some more dialectical... eh, big mess of a problem that we're surely evolving towards a solution for. > > >>DB's are a lot faster than Clipper now, and can store alot more too. > > Hmmm Faster? DB are running on PC 1000 times faster than in the 80's, > this makes a big diffference. > About 7 years ago, I wrote an interpreter for a script language > ColdFusion like, > but based on the Clipper syntax instead of SQL, and believe it or not, > it was FASTER > than ColdFusion! ;-) And it was not written in C nor in Java, but 100% > in Clipper! I don't doubt speed in certain areas is vastly different than others, but I have to qualify that I've personally written applications that /screamed/ <mutter>when I was the only one using them</mutter>. LOL. Seriously, there is a *lot* going on besides raw data IO. Just look at the various DB providers... these things are geared for certain things, and there is only soo much bomber you can put in the fighter, or vice versa. > > >>Yech. Clipper. What a tank. > > Of course, it is completely medieval now, but in its own time it really > was a great product. > And at least it DID HAVE record and table lock facilities, which CF and > SQL do not have! ;-) dbase4 is swell too, but there is a reason why we grew out of it. And a lot of it has to do with connections --stateless or otherwise--, and lots of people working on the same stuff at once... or lots of data. Lots and lots of data. 8 terabytes in one record? *cough* Yeah. Maybe a patch idea, but space is cheaper now, and I can't help but think it's one of the "patch ideas" that might make a whole lot of stuff easier, and, with luck, might even qualify as a "feature". Anyone else using Subversion as a database? ;-) --ps throw in some AJAX, and you could have a live little message pop up "hey, carl wants to edit this same record. Wanna save what you're working on and let him?" or "How much longer you gonna have this locked?" type deal... wow... now /that's/ being connected. But locks are cool... I guess... =P ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting, up-to-date ColdFusion information by your peers, delivered to your door four times a year. http://www.fusionauthority.com/quarterly Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:252463 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4

