Subject | Re: [firebird-support] Re: How to implement SQLServer's WITH(NOLOCK) statment? |
---|---|
Author | Nando Dessena |
Post date | 2008-04-14T12:29:48Z |
Yoni,
r> From the SQL server help file:
r> "In SQL Server, a SELECT statement with the default isolation level
r> of Read Committed causes S locks being taken and released on rows as
r> they are read. Although this enforces the isolation level, it means
r> that a SELECT statement waits if an incompatible lock exists on a row
r> for which an S lock is required. When the NOLOCK hint is specified,
r> the SELECT operation does not try to take the S lock and the data is
r> read. Although this lets the operation succeed, it also means that
r> the SELECT statement can read uncommitted data."
r> In practice what it means that select statments never get locked. and
r> this is what I'm tring to achieve.
as others told you, in Firebird this is the standard behaviour, under
the aforementioned circumstances. And without the drawback of reading
uncommitted data, I might add. In short, you don't need to add
anything to your select statement to make it lock-free. And, you
won't even incur the risk of reading uncommitted data.
Ciao
--
Nando Dessena
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================
r> From the SQL server help file:
r> "In SQL Server, a SELECT statement with the default isolation level
r> of Read Committed causes S locks being taken and released on rows as
r> they are read. Although this enforces the isolation level, it means
r> that a SELECT statement waits if an incompatible lock exists on a row
r> for which an S lock is required. When the NOLOCK hint is specified,
r> the SELECT operation does not try to take the S lock and the data is
r> read. Although this lets the operation succeed, it also means that
r> the SELECT statement can read uncommitted data."
r> In practice what it means that select statments never get locked. and
r> this is what I'm tring to achieve.
as others told you, in Firebird this is the standard behaviour, under
the aforementioned circumstances. And without the drawback of reading
uncommitted data, I might add. In short, you don't need to add
anything to your select statement to make it lock-free. And, you
won't even incur the risk of reading uncommitted data.
Ciao
--
Nando Dessena
======================================================
I support Firebird, I am a Firebird Foundation member!
Join today at http://www.firebirdsql.org/ff/foundation
======================================================