| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Блокировка таблицы транзакцией в MSSQL [D7, MSSQL]
lats © (2005-02-07 08:25:00)Начинаю транзакцию. При этом блокируется таблица или даже вся база. Испльзую ADO.
lats (2005-02-08 15:42:00) [21]Я сделал так. Удаляю свою родительскую таблицу, а дочерние сами удаляются, т.к. связанные мо ключевому полю и выполнено каскадное удаление. Т.е. все изменения также отменяются. Может тебе тоже поможет.
Serggg (2005-02-08 15:23:00) [22]И потом, как мне тогда организовать откат изменений? Если я отменяю все изменения начиная с какого-то опред. момента? ИМХО, кроме как транзакцией не получится. :(
Serggg (2005-02-08 15:17:00) [23]Так блин сервак даже на чтение не открывает данные :(
Desdechado (2005-02-08 15:10:00) [24]2 roottim
Пишущие транзакции все равно должны быть короткоживущими. Даже в ИБ, хоть он и версионник. Потому как если ты открыл данные для изменения, то остальные-то не смогут их тоже открыть для изменения. И это не зависит от структуры сервера.
Кстати, оракл ты зря к версионникам отнес. Имхо, типичный блокировочник.
Serggg (2005-02-08 15:05:00) [25]Да вот не помогает TRANSACTION ISOLATION LEVEL. READ UNCOMMITTED :(
Nikolay M. (2005-02-08 14:04:00) [26]
> по слухам, мсскл тоже планирует переходить на версионную
> архитектуру ?
В Yukon-е. Кажется, третья бета уже вышла.
roottim (2005-02-08 13:53:00) [27]> зато транзакция коротко-живущая и более гибкая
собственно смысла тразакции, в короткоживущих ее реализациях, - никакого.
Это "проблема" блокировочных систем аля мсскл, в которых
чем быстрее протекает транзакция тем быстрее снимается блокировка,
отчего и разработку нужно вести в этом ключе.
Для версионников (oracle, FB, postgres) приемущество транзакций остаются в силе на довольно продолжительное время. Вот тут действительно целостность и гибкость, правда можно нарваться на snapshot too old (для оракла), но это уже другая песня.
Помоему, по слухам, мсскл тоже планирует переходить на версионную архитектуру ?
Ega23 (2005-02-08 13:18:00) [28]Я всегда Isolation level для транзакции выставлял...
Nikolay M. (2005-02-08 11:27:00) [29]
> мне надо, чтобы юзер вносил изменения в главную и подчиненную
> таблицы, но мог это все дело отменить. Типа "Сохранить изменения?
> Да/нет"
Из этого не следует, что нужно делать так:
> транзакция начинается при начале изменениий (на BeforeEdit,
> например).
Если бы все так делали, то
> с ним ввобще бы никто не работал.
Транзакция всегда должна быть как можно более короткой по времени. Кстати, почитай еще про SET TRANSACTION ISOLATION LEVEL. READ UNCOMMITTED может тебе помочь, но можешь нарваться на грабли.
Nikolay M. (2005-02-08 11:27:00) [30]
> мне надо, чтобы юзер вносил изменения в главную и подчиненную
> таблицы, но мог это все дело отменить. Типа "Сохранить изменения?
> Да/нет"
Из этого не следует, что нужно делать так:
> транзакция начинается при начале изменениий (на BeforeEdit,
> например).
Если бы все так делали, то
> с ним ввобще бы никто не работал.
Транзакция всегда должна быть как можно более короткой по времени. Кстати, почитай еще про SET TRANSACTION ISOLATION LEVEL. READ UNCOMMITTED может тебе помочь, но можешь нарваться на грабли.
aus (2005-02-07 19:57:00) [31]Набор данных скорее всего не блокируется, а переходит в Zombie State, о чем выдается сообщение (по кр. мере у меня так было).
Вот это мне помогло:
with (DataSet as TCustomADODataSet).Properties do begin
Item['Preserve on Commit'].Value := true;
Item['Preserve on Abort'].Value := true;
end;
Desdechado (2005-02-07 16:24:00) [32]транзакцию начинай после нажатия на сохранить:
1. создаешь мастер-записи
2. получаешь их коды
3. создаешь деталь-записи
4. подтверждаешь/откатываешь транзакцию
ручной работы больше, чем при автомате, зато транзакция коротко-живущая и более гибкая
Serggg (2005-02-07 16:17:00) [33]danilka, так у меня мастер-детальные таблички (главная и подчиненная), и если главная табличка будет кэшироваться, тов ней первичный ключ (до UpdateBatch) будет пустой, а значит я не смогу добавить строки в детальную табличку. А транзакция начинается при начале изменениий (на BeforeEdit, например). Т.е. мне надо, чтобы юзер вносил изменения в главную и подчиненную таблицы, но мог это все дело отменить. Типа "Сохранить изменения? Да/нет"
Danilka (2005-02-07 11:49:00) [34][2] Serggg (07.02.05 11:09)
Не надо при начале стартовать транзакцию. Смотри справку по UpdateBatch.
[3] lats © (07.02.05 11:18)
Вообще, так я не делал еще с МС-Скулем, все как-то сначала сохраняешь мастер-запись, а потом уже детальные таблицы заполняешь. Но, думаю, опять-же все можно провернуть через клиентские курсоры и UpdateBatch, только нет здесь МС-Скуля проверить, сам смотри и пробуй.
Sergey13 (2005-02-07 11:27:00) [35]2lats © (07.02.05 08:25)
Я с этим сервером не работал, но что то слабо верится. ИМХО, если бы это было так, то с ним ввобще бы никто не работал. 8-)
lats (2005-02-07 11:18:00) [36]Дело в том, что транзакция начинается перед созданием записи в первой таблице, потом создаются записи во второй и третьей таблице, которые ссылаются на ключевое поле первой. Причем на любом этапе добавление записи(ей) можно отменить. Конечно при отмене можно удалять запись в первой таблице, но для этого много переделывать. Может есть какой другой способ?
Serggg (2005-02-07 11:09:00) [37]Аналогичная проблема. У меня при начале работы таблицы включается транзакция (чтобы можно было откатить изменения), при этом напрочь блокируется чтение к таблице (хотя свойство в ADO-компоненте - Optimistic). Как получить-таки доступ на чтение таблички для других юзверей?
Danilka (2005-02-07 09:31:00) [38]И что? Пущщай блокируется. :)
Транзакцию следует начинать и заканчивать в одной процедуре - процедуре записи, и те доли секунды, что она будет отрабатывать, блокировка нескольких записей (а не вся таблица) никому не помешает.
| |
Страницы: 