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 Received on Thu Nov 27 1997 - 00:00:00 CET