Silicon Investor (SI) -- The First Internet Community

STOCKTALK

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor. We ask that you disable ad blocking while on Silicon Investor in the best interests of our community. If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.

Technology Stocks : IFMX - Investment Discussion -- Ignore unavailable to you. Want to Upgrade?

To: Rob Cook who wrote (8782)	1/15/1998 4:29:00 PM
From: Jyoti sharma	Read Replies (1) \| Respond to of 14631

Rob and all, Here is something to cheer or despair. M Murphy of CTSL is bullish on Informix from yesterday's smart money:: " Informix (IFMX), a badly beaten rival to Oracle, should straighten out its problems soon, while it posted a surprisingly small loss in the fourth quarter; thus, Murphy has 5% of his assets under management invested in the stock " the link is: smartmoney.com Good investing Jyoti

To: Rob Cook who wrote (8782)	1/15/1998 4:59:00 PM
From: Charles Hughes	Respond to of 14631

>>>Well, not quite. If I recall, with a clustered index, you were forced to lock the target page that would hold the new row as opposed to just throwing the row unto a free slot anywhere).<<< This exception has some truth to it, because clustered indexes were essentially sequential files (no data section - it's all in the index section and it's all sorted optimally.) So the problem wasn't that you couldn't lock the row, but that their brain-dead techniques involve locking whole sectors. However, there were already always complete work-arounds for this situation, because of the logical facts. Nobody else yet wanted the row or needed to know it was there, during the insert process. Just after was soon enough. (I have been through this, in a very active 120-user database.) However, when updates are involved there are logical conflicts that occur that cannot be flexibly solved both with transaction integrity and no row locking. The work-arounds required are nasty and underperforming, and often depend on non-database codeing and messaging. IMNSHO. ;-) Chaz