Re: Informix vs. Sybase vs. Oracle vs. (gasp) MS SQL Server

Tim Schaefer wrote: > I wrote: > > > 3) Swich to Informix :-) > > > > I feel tempted to state the same here, but I'd rather ask why > > some of Informix's top programmers have jumped ship and joined > > Orable? (According to what I've read recently in the trade > > papers) > > > > M O N E Y It must have been a lot to be so easily seduced. Either that or Informix weren't paying well. The impression I got was that Informix are in trouble. Can anyone confirm or deny? > The secret is indeed: in not performing a lock on the row till you're > absolutely damn sure it's time to perform the update. Simply select > the data into the form, and save off the original information in a save > buffer. Allow the user to edit the form, and allow them to either update > or change their mind and restore the screen. [snip] > Should they get around to actually updating the row, check first to > see if it *can* be done ( DECLARE CURSOR ... FOR UPDATE ) If the declare > comes back clean, by checking the SQLCA, perform the update. Otherwise > alert the user that the row is locked please wait. They'd still have to signal their intent so that the data doesn't get changed underneath them in the intrim. Using a server lock for this is the wrong approach. Setting a flag in a key table or making an entry somewhere else (with no held lock) is better. > My code generators do this. It's still no excuse to allow page-level > locking. Row-level locking in my not so humble opinion *is* > important. :-) If you have a highly active OLTP environment, you > should not introduce a page-level only data base into that environment > and add risk. I know a Sybase programmer who shared his "trick" for > working with this inherent problem. But it involves a stored procedure > which adds overhead, and I think the above numbering scheme for serial > numbers. More work than is really necessary, and a lot of wasted > space in the data base. I had worked with a Sybase setup that used a "lock" table. The environment was highly active. Absolutely everything was done via stored procedures (for added performance). Making one extra call at the start to record a "lock" and one at the end to delete it was a negligible overhead. Space usage was negligible too. At the close of each day no space was used (apart from the extra transactions recorded in the log). > Those that argue against sloppy programming definitely are on the > right track. Programs should include the additional management of > checking the row to see if it can be updated, and only do the update > when it's absolutely time to do so. That should make it a > get-in-and-get-out proposition. > > As far as Pablo's comments, I saw bait, and that silly smile with a > baloon on his head. Yeah, the pretzelhead fools everyone. -am