Локшин Марк savosin_sergeyвозможно ли это где-то настроить? или придётся логику добаления в таблицу переносить на сервер БД? (всякие там view + триггер instead insert)?
Обрабатывайте событие DataWindow sqlpreview.
А по моему легче написать ХП и обновлять через них, чем возиться с SQLPreview.

savosin_sergey2 ASCRUS: то есть, dw.update() вообще не использовать?
Это почему не использовать ??? Отключаете в DW UpdateProperties, включаете StoredProcedureUpdates. PB будет не сам скрипты генерить на обновление, а вызывать указанные ХП соотвествующе на добавление, обновление и удаление, в которых Вы и напишите свой Insert c блокировкой таблицы.

P.S. Я только никак не понимаю, зачем при вставке записи блокировать всю таблицу :)

savosin_sergey2 ASCRUS: вот, http://www.sql.ru/forum/actualthread.aspx?tid=189052#1590905
Так не легче ли в триггере на получение максимального номера документа в SELECT через хинт ставить уровень SERIALIZABLE, чем блокировать всю таблицу ? Это "притормозит" до окончания Вашей транзакции все остальные DML операторы на таблицу. Вы же вообще режите любые операции над таблицей - то есть при таком хинте Ваша транзакция во первых будет ждать, пока все транзакции на таблице закончаться, во вторых во время выполнения будет не только "резать" вставляющих записи, но и вообще всех, даже читателей. Какой в этом глубокий спрашивается смысл ?

IMHO - не нужно кривизну проектирования БД решать посредством хинтов. Я не знаю логики Вашего приложения, но в случаях, если у Вас могут допускаться разрывы в номерах документов, то вообще легче поставить хинт в триггере на грязное чтения и никого не блокировать лишний раз. Так же можно увести логику с триггера в ХП, ответственной за добавление записей, в MSSQL лучше осторожничать с триггерами, это не ASA :)

Я бы лично модифицировал второй способ. Не делал там инкрементное поле, а сделал таблицу только с одной записью и одним полем, в котором бы хранил последнее актуальное значение номера. Тогда бы схема работы выглядела так в ХП на добавление записи в tdocument:
1. Получаем новое значение счетчика, одновременно его увеличивая (UPDATE tdocument_num SET @Number = Number = Number + 1), таким образом вешаем экслюзивную блокировку на эту запись в таблице и сразу его получаем новое значение в переменную @Number.
2. Вставляем запись (INSERT INTO tdocument) уже сразу с присвоенным номером (в ней же можно для уверенности организовать UNIQUE, конечно если нет NULL полей, определяющих уникальность).

Клиент PB на добавление записи через Stored Proc Update вызывает эту ХП, передает значения полей в параметры, она отрабатывает. Далее как обычно COMMIT или ROLLBACK, в зависимости от того, что вернула DW.UPDATE().

Что теперь будет с другими сессиями ? Ничего страшного. Все будут работать как обычно, никаких deallock, кто одновременно пытается добавить записи будут ждать, пока update по commit освободит запись. Таким образом не будет разрывов, триггеров на MSSQL и никто не будет занимать лишнее места (зачем спрашивается с инкриментом или генераторами связываться, когда они изначально был сделан именно для того, чтобы не реагировать на транзакции).

P.S. Давно я на MSSQL ничего не делал, но наверное так бы и сделал, причем и на ASA тоже - мне кажется для блокировочников неплохое должно быть решение. Кстати если в таблицу еще ввести поле Имя, то таким образом можно в одной табличке хранить множество ведения собственных именованных счетчиков для разных нужд.

savosin_sergeyРазве вместо вызода хранимой процедуры можно повесить триггер на update таблицы документа.
Я лично не рекомендую - Вы опять можете нарваться на deadlock-и и другие неприятные ситуации. Смысл в том, что в моем варианте Вы получаете и блокируете номер ДО начала операции вставки документа, а в AFTER триггере MSSQL номер будет получаться и блокироваться ПОСЛЕ вставки документа в таблицу.

savosin_sergeyИ осталось разобраться с блокировкой таблицы со счётчиками, так как при откате транзакции возможны "дыры" в нумерации строк документа, см. .. Я имею ввиду, что (может быть) блокировать update, в котором изменяется значение счётчика мало, надо гарантировать работу триггера в одиночестве . То есть, пока он не завершится или не произойдёт откат транзакции, другой триггер не должен обращаться к таблице счётчиков (или к строке, соответствующей счётчику этого документа для дебета "106").
Дыр не будет. В таблице tdocument_number нет инкремент полей - поле Number обычное int поле и обновляем мы его через UPDATE вручную, прибавляя для каждого нового документа единичку. Соотвествующе номер участвует в транзакции и если например она выполнится не успешно, то там так же будет откачен назад номер полученного документа, остальные же, кто пытается вставить запись, в это время по любому в "зависшем" состоянии ждут, пока с таблицы снимется блокировка. Соотвествующе если документ прошел по COMMIT, они получат новый номер, если не прошел по ROLLBACK, они получат тот же номер, который не смогла задействовать откатившая транзакцию сессия.

Так что мои 3 совета:
1. Откажитесь от триггера
2. Сделайте как я написал - создайте табличку с полем Number, добавьте в нее запись, напишите ХП и прицепите ее к PB
3. Почитайте поподробнее о транзакциях, блокировках и инкрементах в MSSQL, чтобы иметь более внятное представление обо всем этом.