Re: SQL Server vs INFORMIX

On 7 Oct 1997, Reiner Kunz wrote: > Hi Richard, > > where's the problem of no row-level-locking? In your opinion each database > using other locking methods are garbage. So, please tell me where do you > see the big disadvantage of no row-level-locking during UPDATEs and > DELETEs? Alright, I'll address these points in order. First, these days I expect my RDBMS to be a tool and to work around my needs, not force me to work around its limitations. Allowing me to specify a lock level (ie: system, table, row, or even page) is the correct solution here. The big disadvantage of page level locking during updates? Let me bring out exhibit A, an application we're currently porting from SQL server. As part of the design, there are some stored procedures that do several consecutive UPDATEs, all within a single transaction. The problem? Because they all work on the same data (ie: similar tables, NOT identical rows), we're seeing almost a 5:1 success:deadlock condition under load. Becase there is no true deadlock, only faux-deadlocks causedd by data being accessed on the same page, there seems no way to avert this (we've tried oclustering, et cetera, and had some nice MS people bash their heads against the problem for some time. Solution? Port). The real answer? Let the DBA or developer make the call about locking requirements. If they want to use page locking, let 'em. Otherwise they can do what they will. -Richard