Здравствуйте, <Аноним>, Вы писали:

M>>Пользовательские блокировки вполне держатся не на время транзакции, а на время сессии, если мне память не изменяет.
А>Тут некоторые вопросы с названием ресурсов, на которые делается лок, откуда эти названия берутся, точнее как их определить, по имени в ресурсах что-ли, пока ничего не в голову не лезет.

Я для именования ресурса в sp_getapplock склеиваю имя таблицы с значением первичного ключа. Т.е. открывает пользователь форму для редактирования заказа с PK = 123 — лочится ресурс "orders123". Имхо, sp_getapplock/sp_releaseapplock — как раз то, что тебе нужно...

Здравствуйте, <Аноним>, Вы писали:

1) не дать поменять второму открывшему (смотри в сторону блокировок)
2) или проверить, что кто-то что-то поменял в записи, пока читали и думали, перед сохранением?
используй (например в MS SQL Server 2000) тип поля timestamp.
примерно так:
считал .... стичай и поле timestamp
отредактировал в 'кеше' ...
хочешь сохранить — заблокируй запись на изменение ...
считай ЕЩЁ раз поле timestamp и сравни с сохранённым в 'кеше',
если одинаково
сохраняй
иначе (сервер БД сам поменяет значение поля, если кто-то меняет запись)
уведомляй пользователя о том, что кто-то уже что-то поменял и далее по логике, например
считывай новые значения на редактирование в 'кеш'

Здравствуйте, KGP, Вы писали:

KGP>Здравствуйте, <Аноним>, Вы писали:

KGP>2) или проверить, что кто-то что-то поменял в записи, пока читали и думали, перед сохранением?
KGP>используй (например в MS SQL Server 2000) тип поля timestamp.

Спасибо, я правда думаю использовать поле GUID для этих целей, правда при обновлении нескольких таблиц есть некоторые сложности, но имхо это разрешается логикой поведения.
Есть встречный вопрос, как узнать, заблокирован ли какой-либо ресурс? Есть sp_lock, но там нужен id процесса, но его получить в клиенте? И еще, есть ли способ задать время жизни конкрентой транзакции средствами TSQL?
Еще раз спасибо всем, кто ответил.

Здравствуйте, Аноним, Вы писали:

А>Есть встречный вопрос, как узнать, заблокирован ли какой-либо ресурс? Есть sp_lock, но там нужен id процесса, но его получить в клиенте?
А>И еще, есть ли способ задать время жизни конкрентой транзакции средствами TSQL?

Ты явно идешь неправильным путем... Я очередной раз хочу посоветовать тебе посмотреть в сторону пользовательских блокировок, они как раз для таких случаев и придумывались.
Вся информация о блокировках строк в таблице — системная и использовать ее можно только для отладки.
Во-первых никто, никогда не гарантировал ее согласованности, во вторых подобное решение будет полностью немасштабируемо и совершенно не факт, что заработает даже не аналогичной системе.
Для того чтобы использовать внутренний менеджер блокировок сиквела в своих целях, существуют пользовательские блокировки, они предоставляют весь необходимый функционал.
Лезть для этого в системные таблички нет никакой необходимости.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Аноним, Вы писали:


M>Ты явно идешь неправильным путем... Я очередной раз хочу посоветовать тебе посмотреть в сторону пользовательских блокировок, они как раз для таких случаев и придумывались.

Да, вообще-то не иду таким путем, который вытекает из моего вопроса. Мне просто интересно до конца докопать вопрос. Лезть в менеджер блокировок, согласен не стоит. А пользовательские блокировки — действительно интересная вещь, спасибо за подсказку.

Здравствуйте, <Аноним>, Вы писали:

KGP>>Здравствуйте, <Аноним>, Вы писали:

А>Спасибо, я правда думаю использовать поле GUID для этих целей, правда при обновлении нескольких таблиц есть некоторые сложности, но имхо это разрешается логикой поведения.
1) Я не понимаю зачем тебе GUID, тебе ведь не уникальность нужна а check на изменение записи.
А>Есть встречный вопрос, как узнать, заблокирован ли какой-либо ресурс? Есть sp_lock, но там нужен id процесса, но его получить в клиенте? И еще, есть ли способ задать время жизни конкрентой транзакции средствами TSQL?
2) Я совершенно согласен с Merle что на такие манёвры, как sp_lock, лучше не идти.
Узнать заблокирован ли ресурс ... зачем, если для того, чтоб заблокировать — бери и блокируй, не получится — значит он уже заблокирован.
Предлагаю 'время жизни транзакции' определять именно пользовательские блокировки
А у пользователя на форме изменения ставишь таймер и либо тот САМ продлевает (он 'типа' думает), либо пересчитывать данные и запрос — а ещё разок заблокируем эту запись и как тока ДА — пересчитать данные и опять пользовательские блокировки плюс таймер ...

Здравствуйте, Аноним, Вы писали:

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

select 
    convert (smallint, req_spid) As spid,
    rsc_dbid As dbid,
    rsc_objid As ObjId,
    so.name as ObjName, 
    rsc_indid As IndId,
    substring (v.name, 1, 4) As Type,
    substring (rsc_text, 1, 16) as Resource,
    substring (u.name, 1, 8) As Mode,
    substring (x.name, 1, 5) As Status
from     master.dbo.syslockinfo sl
        INNER JOIN master.dbo.spt_values v ON sl.rsc_type = v.number
    INNER JOIN master.dbo.spt_values x ON sl.req_status = x.number
    INNER JOIN master.dbo.spt_values u ON sl.req_mode + 1 = u.number
        LEFT JOIN sysobjects so ON sl.rsc_objid = so.ID
where   v.type = 'LR' and x.type = 'LS' and u.type = 'L' and so.Name =
'<имя таблицы>'
order by spid, Type, Resource

Который показывает всю нужную мне информацию о блокировках, которые наложены на таблицу с заданым именем.

Здравствуйте, KGP, Вы писали:

KGP>Здравствуйте, <Аноним>, Вы писали:

KGP>>>Здравствуйте, <Аноним>, Вы писали:

А>>Спасибо, я правда думаю использовать поле GUID для этих целей, правда при обновлении нескольких таблиц есть некоторые сложности, но имхо это разрешается логикой поведения.
KGP>1) Я не понимаю зачем тебе GUID, тебе ведь не уникальность нужна а check на изменение записи.

Вот с помощью GUID можно сделать небольшую проверку на изменение записи. Просто менять значение GUID
при Update.

А>>Есть встречный вопрос, как узнать, заблокирован ли какой-либо ресурс? Есть sp_lock, но там нужен id процесса, но его получить в клиенте? И еще, есть ли способ задать время жизни конкрентой транзакции средствами TSQL?

KGP>А у пользователя на форме изменения ставишь таймер и либо тот САМ продлевает (он 'типа' думает), либо пересчитывать данные и запрос — а ещё разок заблокируем эту запись и как тока ДА — пересчитать данные и опять пользовательские блокировки плюс таймер ...

Да это ясно, интересно, есть ли в сервере такая возможность, собственно весь вопрос интересует именно с точки зрения _сервера_ и TSQL.
Спасибо за ответ.

Здравствуйте, <Аноним>, Вы писали:

А>Вот с помощью GUID можно сделать небольшую проверку на изменение записи. Просто менять значение GUID
А>при Update.
Самому менять GUID?
timestamp сервер поменяет при update.

Здравствуйте, KGP, Вы писали:

KGP>Здравствуйте, <Аноним>, Вы писали:

А>>Вот с помощью GUID можно сделать небольшую проверку на изменение записи. Просто менять значение GUID
А>>при Update.
KGP>Самому менять GUID?
KGP>timestamp сервер поменяет при update.

Угу, я уже прочитал. Просто в рамках моей задачи возможно совместить GUID еще с одной задачей

Здравствуйте, <Аноним>, Вы писали:

если используешь адо.нет — то там эти вопросы решаются легко с помощью параллелизма

Здравствуйте все!

Я конечно извиняюсь, может не внимательно читал BOL и что-то не понял, но как установить хинт (updlock) или еще как блокирнуть (без пользовательских блокировок) на записи возвращаемые след. запросом
SELECT * from [X] LEFT JOIN [Y] on .... where....
Точнее, как я понял его вообще не установишь на такой запрос, что вроде как разумно и так и должно быть. Но как быть в таком случае?

Здравствуйте, Аноним, Вы писали:

А>Точнее, как я понял его вообще не установишь на такой запрос, что вроде как разумно и так и должно быть. Но как быть в таком случае?
Вообще установить можно, если надо и на таблицу X и на таблицу Y, то примерно так:

SELECT * from [X] WITH(UPDLOCK) LEFT JOIN [Y] WITH(UPDLOCK) on .... where....

Можно попытаться дописать WITH(UPDLOCK, ROWLOCK), но все равно, гарантии, что заблокируется только одна строка — никто не даст.
Подробности вот здесь: http://www.rsdn.ru/?article/?451

Автор(ы): Иван Бодягин
Дата: 03.11.2003
В этом небольшом Q&A рассматривается «проблема» эскалации блокировок (lock escalation). Слово «проблема» намеренно взято в кавычки, так как на самом деле это никакая не проблема, а достаточно остроумное решение других потенциальных проблем. Сначала я попытаюсь объяснить, что же такое эскалация и для чего она предназначена, а потом будет разобрана реализация эскалации блокировок в Microsoft SQL Server 2000.

Здравствуйте, Merle, Вы писали:

M>SELECT * from [X] WITH(UPDLOCK) LEFT JOIN [Y] WITH(UPDLOCK) on .... where....
M>[/sql]
Упппссс! Совсем я заработался Спасибо, просто я что-то не так писал, для обычного select все нормально проходило, а в JOIN QA меня посылал. Полез в BOL — там еще больше пурги...

M>Подробности вот здесь: http://www.rsdn.ru/?article/?451

Автор(ы): Иван Бодягин
Дата: 03.11.2003
В этом небольшом Q&A рассматривается «проблема» эскалации блокировок (lock escalation). Слово «проблема» намеренно взято в кавычки, так как на самом деле это никакая не проблема, а достаточно остроумное решение других потенциальных проблем. Сначала я попытаюсь объяснить, что же такое эскалация и для чего она предназначена, а потом будет разобрана реализация эскалации блокировок в Microsoft SQL Server 2000.

А вот за эту ссылочку просто огромное спасибо.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте. Возможно у меня дурацкий вопрос.
А>Есть два клиента, оба одновременно правят одну и туже запись.
А>Действия клиента.
А>1. Читаем данные из бд
А>2. Кешируем их
А>3. Пользователь редактирует данные в кеше.
А>4. Открываем транзакцию, пишем в бд, закрываем транзакцию

А>Вот теперь вопрос, при записи данных 1 клиентом в бд, 2 клиент, не записавший еще
А>их в бд имеет у себя в кеше недостоверные данные. Как при записи данных 2 клиентом проверить, не внес ли кто до него
А>изменения? И в этом случае не дать выполнить изменения ?
А>Держать открытой транзакцию на все время жизни форма(диалога) — имхо не верно.
А>Проверять ручками на верность записей — вроде тоже маразм. Как это решается правильно?

К сожалению, не могу похвастаться высоким уровнем знаний и практическим применением оных. Но подобные вопросы подробно рассматривались в книге Тома Кайта "Oracle для профессионалов". Рекомендую посмотреть там. Конечно, книга посвещена Oracle. Так, что ответ скорее профильный.

A_T>К сожалению, не могу похвастаться высоким уровнем знаний и практическим применением оных. Но подобные вопросы подробно рассматривались в книге Тома Кайта "Oracle для профессионалов". Рекомендую посмотреть там. Конечно, книга посвещена Oracle. Так, что ответ скорее профильный.

что для версионика хорошо — блокировочнику смерть.

Gt_

Здравствуйте, Alice_The_Fox, Вы писали:

A_T> Но подобные вопросы подробно рассматривались в книге Тома Кайта "Oracle для профессионалов".
Если мне не изменяет память, то у Тома Кайта про это только полторы страницы довольно невнятного текста, в то время как про это дело можно многотомник написать.

Здравствуйте, Merle, Вы писали:

M>Здравствуйте, Alice_The_Fox, Вы писали:

A_T>> Но подобные вопросы подробно рассматривались в книге Тома Кайта "Oracle для профессионалов".
M>Если мне не изменяет память, то у Тома Кайта про это только полторы страницы довольно невнятного текста, в то время как про это дело можно многотомник написать.

Там больше ДАЖЕ 2 страниц — фактически, этому посвящена как минимум одна глава (правда с легкими лирическими отклонениями от темы )

Здравствуйте, Alice_The_Fox, Вы писали:

A_T>Там больше ДАЖЕ 2 страниц — фактически, этому посвящена как минимум одна глава (правда с легкими лирическими отклонениями от темы )
Ну да, глава из полутора страниц, посвященная лирическим отсуплениям...
Вообщем, если не собираешься делать это под Оракл, то ориентироваться на Тома Кайта не стоит, он конечно хороший дядька, но мы его любим за другое...