> Hi,
> I have a view created thus:
[quoted text clipped - 47 lines]
>
> Chris Hough
To avoid lock contention, have you considered snapshot isolation?
Chris Hough - 18 Nov 2008 18:42 GMT
Many of our clients are still on SqlServer 2000 and have no immediate plans
to upgrade, so I would prefer to have a strategy that will work for 2000
onwards.
> Hi,
> I have a view created thus:
[quoted text clipped - 28 lines]
>
> This view does a large number of joins, but is never used to update data.
If other processes update data than can be in the range of the View (or
Select query), then using the Nolock hint could return bad (corrupted) data
or an error message such as 601 or 605. See for example
http://blogs.msdn.com/craigfr/archive/2007/06/12/query-failure-with-read-uncommi
tted.aspx
> My questions:
>
> Does the setting of the TRANSACTION LEVEL cause all my tables
> and joins to behave as if each one had a WITH (NOLOCK) clause added?
Absolutely not. The View is created without any regard to the current
Transaction Isolation Level. If you want your view to behave with the NoLock
hint, then you must add it explicitely in the Create View statement.
> Do I actually have to have a transaction surrounding the SELECT statement
> in order to use SET TRANSACTION LEVEL (it would seem so)?
Not necessarily. For example, if you use the Read Uncommitted level and
then have a select statement without an *explicit* around it, then this
select statement will still be executed like with the NoLock hint.
> What is the simplest way to cause some of my large Views to implement
> completely
> a NO LOCK strategy?
You must use the Set Transaction Isolation Level Read Uncommitted around it
when you're calling it or you must add the NoLock hint when creating your
view.
> It is obviously more convenient to have the view stored in
> the database to have the SQL necessary to accomplish my goal, but I am
[quoted text clipped - 3 lines]
>
> Chris Hough

Signature
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: sylvain aei ca (fill the blanks, no spam please)
In your example below, SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED; GO;
is part of another batch, becuause it's seperated by a GO statement. Besides,
you cannot include a use the SET statement or any other statement except
SELECT within a view.
I don't know of a way to hard code transaction isolation level within the
view, except to use the (nolock) hint. However, you can SET TRANSACTION
ISOLATION LEVEL as part of your ADO connection, prior to selecting from the
view, and this setting will remain in effect for the duration of the
connection.
> Hi,
> I have a view created thus:
[quoted text clipped - 47 lines]
>
> Chris Hough