Народ !

Чем принципиально отличаются следующие два фрагмента кода:

... ПЕРВЫЙ

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
SELECT @CUSTID = MAX(CUSTID) FROM CUSTOMERS
SET @CUSTID = @CUSTID+1
INSERT INTO CUSTOMERS (CUSTID, ...) VALUES (@CUSTID, ...)
COMMIT

... ВТОРОЙ

BEGIN TRANSACTION
SELECT @CUSTID = MAX(CUSTID) FROM CUSTOMERS WITH (TABLOCKX)
SET @CUSTID = @CUSTID+1
INSERT INTO CUSTOMERS (CUSTID, ...) VALUES (@CUSTID, ...)
COMMIT

Надо ли в первом примере включать WITH (TABLOCKX) в SELECT ?

В чем тонкость и как это работает ?

>>Я Вам советую ради интереса поставить SQL Server, п.ч. абстрактное изучение >>документации без экспериментов мало что дает.

SQL Server стоит (Personal Edition 7.0 SP2), так что это не совсем абстрактное изучение

Но вот что странно, кусок №1 не работает, т.е. работает не корректно.
Я открыл две сессии в QA и запустил кусок №1 с небольшой модификацией:

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION
SELECT @CUSTID = MAX(CUSTID) FROM CUSTOMERS
SET @CUSTID = @CUSTID+1

WAITFOR DELAY '00:00:02'

INSERT INTO CUSTOMERS (CUSTID, ...) VALUES (@CUSTID, ...)
COMMIT

в одной сессии и без WAITFOR DELAY '00:00:02' в другой сессии, на пол секунды позже чем в первой.

Так вот в той сессии где без WAITFOR все завершилось успехом без какого либо ожидания разблокировки таблицы, а в сессии с WAITFOR DELAY '00:00:02' произошла ошибка (дублирование перв. ключа) ?????

ПОЛУЧАЕТСЯ, ЧТО [SET TRANSACTION ISOLATION LEVEL SERIALIZABLE] - работает "несколько" не так, как мы думаем ????

Напротив, если использовать WITH (TABLOCKX) и провести тот же тест с WAITFOR DELAY '00:00:02' то все работает корректно, но как уже говорилось Вами и я с этим согласен, это как то некрасиво и неэффективно (

КАК ЖЕ ВСЕ ТАКИ ПРАВИЛЬНО ???
=============================

А по поводу @@Error я не это имел в виду (то что Вы написали - очевидно)
При тесте оказалось, что с @@Error СОВСЕМ НЕ ПОЛУЧАЕТСЯ РАБОТАТЬ(ОБРАБОТАТЬ), т.к.
при возникновении RUNTIME ERROR и установленном SET XACT_ABORT ON происходит вылет
=============
из всех вложенных процедур на самый верхний уровень, другими словами если из QA
запустить PROC1 из которой вызывается PROC2 из которой вызывается PROC3 и т.д. то
при ран-тайм ошибке в PROC3 - вылетаем в QA и ни в PROC2, ни в PROC1 нет возможности
среагировать на ошибку и как то это обработать ((((((((((

Получается вывод: Для нормальной обработки ошибок пользоваться SET XACT_ABORT ON - нельзя. А в BOL пишут, что такой режим очень рекомендуется :-8

И на последок еще один вопрос.
Если все таки пользовать WITH (TABLOCKX) то надо ли его писать один раз или несколько раз, если делается запрос с вложенным запросом на ту же самую таблицу ?
Например:

...

SET IDENTITY_INSERT Products ON
SELECT @nextidentval = MIN(IDENTITYCOL) + IDENT_INCR('Products')
FROM Products with (TABLOCKX) o
WHERE IDENTITYCOL BETWEEN IDENT_SEED('Products') AND 2147483647 AND
NOT EXISTS (SELECT * FROM Products with (TABLOCKX) oo
WHERE oo.IDENTITYCOL = o.IDENTITYCOL +
IDENT_INCR('Products'))
SET IDENTITY_INSERT Products OFF

И еще, как быть со штуками типа IDENT_SEED('xxx'), IDENT_INCR('xxx') - ведь это тоже по сути обращения к таблице (или к схеме) ?

P.S. Не хочу надоедать с надоевшей всем темой, но все таки мне это надо не для праздного любопытства, а для конкретного дела и очень хочется сделать КАЧЕСТВЕННО, ГРАМОТНО и ПРОФЕССИОНАЛЬНО вот такие дела ...

За ссылку на статью Павлу - спасибо. Статья интересная, но у меня используется SQL Server 7.0 (SP2) и UDF там нет
Но общий принцип ясен можно будет воспользоваться.

>>Мне неохота сейчас залезать в дебри уровней изоляции в SQL Server, но из Вашего вопроса мне показалось, что Вы >>хотите сами наращивать значение некоего счетчика и идете по пути нахождения максимального значения и прибавления ему >>единицы. Если я прав в своем предположении, то посоветовал бы Вам задуматься кроме как над блокировками (проблема >>получения действительно максимального значения), еще и над тем, какие у Вас будут таймауты у юзеров, ежели таблица >>разрастется, да даже если и не разрастется

ДЕЛО НЕ В СПОСОБАХ НУМЕРАЦИИ ID (С ЗАПОЛНЕНИЕМ ДЫРОК ИЛИ БЕЗ), меня как раз интересуют вопросы работы БЛОКИРОВОК и
уровни изоляции ТРАНЗАКЦИЙ.

Как я писал выше WITH (TABLOCKX) и SET TRANSACTION ISOLATION LEVEL SERIALIZABLE - это две большие разницы.
Но пользовать WITH (TABLOCKX) при разросшейся таблице - это обречь пользователей на постоянные ожидания (наверное это так).

Вывод получается такой: НАДО ПРИДУМЫВАТЬ СПЕЦИФИЧЕСКИЕ АЛГОРИТМЫ ДЛЯ РАСЧЕТА [ID] (как в вышеупомянутой статье), КОТОРЫЕ ПОЗВОЛЯЛИ БЫ НЕ БЛОКИРОВАТЬ ВСЮ ОСНОВНУЮ ТАБЛИЦУ, А БЛОКИРОВАТЬ ЕЕ (ТАБЛИЦЫ) ЧАСТЬ, ЛИБО БЛОКИРОВАТЬ НЕКУЮ НЕБОЛЬШУЮ ВСПОМОГАТЕЛЬНУЮ ТАБЛИЦУ, ИСПОЛЬЗУЕМУЮ ДЛЯ РАСЧЕТА [ID].

И вот мы подошли к сути вопроса: КАК НЕ ПОЛЬЗУЯСЬ WITH (TABLOCKX) КОРРЕКТНО ЗАБЛОКИРОВАТЬ ЧАСТЬ ТАБЛИЦЫ, (НАПРИМЕР
ПО УСЛОВИЮ НА ИНДЕКС) ??? Ведь SET TRANSACTION ISOLATION LEVEL SERIALIZABLE - не работает так как ожидалось (тогда ЗАЧЕМ ЭТО ВООБЩЕ НУЖНО И ГДЕ ПРАКТИЧЕСКИ ПРИМЕНЯЕТСЯ ???).

Как же все таки быть, как правильно и эффективно ????????

2 Genady

>Как я писал выше WITH (TABLOCKX) и SET TRANSACTION ISOLATION LEVEL SERIALIZABLE - это две большие разницы.
>>Умгу, и в BOL это описано, не понял в чем проблема.
>Ведь SET TRANSACTION ISOLATION LEVEL SERIALIZABLE - не работает так как ожидалось
>>Ожидалось кем? И как эта установка по Вашему должна работать?

В BOL это действительно описано:
The isolation level can be overridden, if necessary, for individual SELECT statements by specifying a table-level locking hint. Specifying a table-level locking hint does not affect other statements in the session. It is recommended that table-level locking hints be used to change the default locking behavior only when absolutely necessary.
И мной ожидалось, что если из двух сессий будет выполнено SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, то при вставке
новой информации (ID) из обеих сессий, та которая начала транзакцию первее заблокирует часть таблицы по индексу, а вторая будет ОЖИДАТЬ завершения транзакции в первой. И если например в третьей сессии попытались изменить существующие данные, то эта третья сессия не будет ожидать первых двух.
А на практике SQL Server срубает вторую и третью сессии и говорит, что они вызывают DEADLOCK !

>Вывод получается такой: НАДО ПРИДУМЫВАТЬ СПЕЦИФИЧЕСКИЕ АЛГОРИТМЫ ДЛЯ РАСЧЕТА [ID]
>Зачем интересно? Мне пришлось использовать подход описанный в статье только раз, да и то только из за специфичности >задачи. А Вам зачем?
>И вот мы подошли к сути вопроса: КАК НЕ ПОЛЬЗУЯСЬ WITH (TABLOCKX) КОРРЕКТНО ЗАБЛОКИРОВАТЬ ЧАСТЬ ТАБЛИЦЫ,
>Опять вопрос - зачем? В чем смысл этой блокировки, что она Вам дает?

У меня порядка 100 одновременно активных сессий, в которых юзера вводят и корректируют информацию, обращаясь к одним и тем же таблицам. И мне надо сделать так, что бы юзера не сидели по часу в ожидании реакции системы на вставку новой или изменение существующей информации (если тупо пользоваться хинтами типа TABLOCKX)

>Ключевой Ваш вопрос - ЗАЧЕМ ЭТО ВООБЩЕ НУЖНО И ГДЕ ПРАКТИЧЕСКИ ПРИМЕНЯЕТСЯ ???
>Бывает, что нужно использовать эти установки, но такая необходимость возникает крайне редко, во всяком случае я даже >с ходу и пример придумать не могу.

Я имел в виду, что если это все работает не так как мной ожидалось, то как практически (ПРАВИЛЬНО) это использовать
для перечисленных мной выше реальных задач

------------------------

2 ALL

Не смотря на столь долгое обсуждение сабжа я к сожалению так и не получил ясного ответа.
Неужели никто не может толково сказать как все таки надо поступить (можно с конкретным примерчиком SQL скрипта)
в моем случае, ведь эта проблема возникает практически у каждого программера, разрабатывающего клиент-серверные
системы, расчитанные на одновременную работу многих пользователей.