Re: lies damn lies and benchmarks

Pablo Sanchez wrote:

> "Daniel Morgan" <dmorgan_at_exesolutions.com> wrote in message
> news:3CDA971D.87DA9797_at_exesolutions.com...
> > Chris Weiss wrote:
> >
> > > Hmmm.... It seems that like in many product wars, people's
> knowledge is out
> > > of date:
> > >
> > > * Sql server had had robust row level locking since version 7.
> Prior to
> > > this it was page locking, which could be clumsy.
> >
> > This is only partially true. It is still quite easy to run out of
> row leve locks
> > in SQL Server and have the row level locks escallate to page level
> locks.
>
> You're incorrect.
>
> Locks can be configured on Version 7 and SQL Server 2000 to be dynamic
> or to set a hard limit. Locks escalate to a next higher up level
> (row -> page -> table) to reduce the overhead in managing the locks
> and minimize the number of resources.
>
> For example, given a table with 1,000,000 rows, would it be better to
> issue a million row level locks or one table lock?

Sort of depends on whether your database has more than one simultaneous user doesn't it.

We are belaboring the point. You know perfectly well, as does everyone else, that every tool has its strong points and its weak points. Locking is not one of SQL Server's strong points.

Daniel Morgan Received on Thu May 09 2002 - 14:42:06 CDT