выборка во время транзакции

← →
jorgunited (2008-04-21 16:18) [0]

Имеется два соединения с MSSQL. На одном из них начинается транкзация во время которой делается UPDATE таблицам.

Далее для того, чтобы сделать commit нужно выполнить ряд действий среди которых выборка из таблиц в которые делался UPDATE. То есть необходимо сделать выборку из них при открытой транкзации. Использование для этого другого соединения приводит к "зависанию" программы. А если использовать первое, то невозможно получить доступ к свойствам после выборки (напр RecordCount).

Механизм DBExpress, D7.

← →
ANB (2008-04-21 16:33) [1]

1) явно отключить блокировку в запросе
2) нехороший алгоритм. Выборку есть смысл делать из той же сессии, где производилось обновление. А лучше что-нибудь придумать и не делать выборку.

← →
jorgunited (2008-04-21 16:37) [2]

1)каким образом?

← →
ANB (2008-04-21 17:16) [3]

> jorgunited (21.04.08 16:37) [2]

а не помню я. посмотри сам в боле.

← →
MsGuns © (2008-04-21 23:02) [4]

Мало что понял из сабжа, но, ИМХО, явно чувствуется излишняя "тяжесть" клиента. Выход - перенос максимума логики на сервер - там и же и явно рулить транзакциями.

← →
sniknik © (2008-04-21 23:30) [5]

чтобы прочитать во время транзакции можно сделать запрос с "грязным чтеним" (FROM WITH READ UNCOMMITTED), он не будет "зависать", но и данные будут частями, записанные + записываемые и которые возможно "откатятся" (а как иначе? оно же пишет в этот самый момент) и станут уже несуществующими. т.е. не пойми что. не дай Гейтс на них основываться... опять будет "мелкосовт масдай". хотя сами получили именно то, чего добивались.
не надо так делать...

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

← →
Германн © (2008-04-22 01:20) [6]

> sniknik © (21.04.08 23:30) [5]

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

Именно так!

> jorgunited (21.04.08 16:18)

Кстати всегда в вопросе лучше приводить задачу, а не частный вопрос. (Кроме очевидных случаев).

← →
jahman (2008-04-22 02:43) [7]

Всё дело в том, что выборку нужно делать именно после модификации данных в процессе транкзации. Эта выборка нужна для последующего сохранения её результата в Excel. А сама транкзация на тот случай, если скажем пользователь нажмет "отмена" на диалоге SaveAs, а модификация в базе данных уже будет произведена. Тогда откат..

запрос
SELECT * FROM datatable1 WITH READ UNCOMMITTED

выдает

Incorrect syntax near the keyword "READ".

Такое впечатление, что автор сабжа - чистый "локальщик" ;)

> выдает
> Incorrect syntax near the keyword "READ".
правильно выдает. я приводил не код для копи пасте, а набор значимых слов для поиска в BOL соответствующего раздела. в том же разделе, кстати, есть ссылка на установку уровней изоляции транзакции о которых говорилось в начале ветки.

> А сама транкзация на тот случай, если скажем пользователь нажмет "отмена"
это самый идиотский вариант использования транзакций. и вообщето они не для того.

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

логика программы нуждается в изменении, а автор вопроса в изучении того что же такое транзакции и для чего нужны.

← →
ANB (2008-04-22 10:48) [11]

> Всё дело в том, что выборку нужно делать именно после модификации
> данных в процессе транкзации. Эта выборка нужна для последующего
> сохранения её результата в Excel. А сама транкзация на тот
> случай, если скажем пользователь нажмет "отмена" на диалоге
> SaveAs, а модификация в базе данных уже будет произведена.
> Тогда откат..

А зачем вообще писать сразу в базу, если не уверены, что это нужно ?

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

В данном случае явно напрашивается сначала набивание временных таблиц, затем вывод отчета и только потом перекладывание в одной транзакции данных в реальные таблицы.
Единственно что непонятно - нахрена нужен отчет по данным, которые не факт что лягут в базу ?

выборка во время транзакции Найти похожие ветки