Oracle, ODAC и блокировки

← →
12 © (2011-01-27 08:55) [0]

Скажите, а если TOraQuery из набора ODAC
поставить CashedUpdates := true, не будет блокировки при прогоне скриптов массовых updatах админом БД?

т.е. ситуация такая
Ночью запускается синхронизация, там много чего апдейтится.
А человек может работать из дома, тоже ночью.

У меня много гридов, во многих разрешено править прямо в гриде, там все равно текст.
А тут запускается синхронизация.

Не бабахнет?

← →
Кщд (2011-01-27 09:42) [1]

12 © (27.01.11 08:55)
Любой DML устанавливает блокировку. Соответственно, update - в частности.
В чем вопрос?

← →
12 © (2011-01-27 10:03) [2]

если будет CashedUpdates := true
блокировка как устанавливается?

только когда я говорю Apply, ведь так?
т.е. прграмма считывает в кэш, работает с этим. Если начался массовый update в БД, ее это не касается, пока apply не скомандовать. Так?
А командуешь apply, программа на короткое время блокирует, массово updaйтит из кэша в бд. Так?

к чему - в данной ситуации
1. никогда нельзя прервать работу скриптов администратора моей программой. т.е. если что - моя должна отказаться.

2. Желательно, что б пользователь не потерял много работы своей. т.е. Если он много чего набил, надо не отменять.

3. ну желательно вообще не терял ничего, конечно

← →
12 © (2011-01-27 10:05) [3]

написал программу(почти), где CashedUpdates := true,
программа гриды, поля показывает - пользователь их правит. Id не трогает.

начальник спросил - будет ли бабах в таком-то случае. Вот думаю - будет ли? Вроде, не должно.
Или как-то переделать, пока время есть?

← →
Кщд (2011-01-27 10:46) [4]

>12 © (27.01.11 10:03) [2]
>если будет CashedUpdates := true
>блокировка как устанавливается?
какой запрос?

PS чем вообще обусловлено желание выставлять CachedUpdates в true?

← →
12 © (2011-01-27 10:51) [5]

в основном такого типа

update Table1 set Field1 = "ЗНАЧЕНИЕ" where Table1.id = Value

редко новые записи вставляются, с ID новыми
например
INSERT INTO BRANCH
(ID_BRANCH, BNAME, ID_FILIAL)
VALUES
(:ID_BRANCH, :BNAME, :ID_FILIAL)

← →
12 © (2011-01-27 11:32) [6]

> ем вообще обусловлено желание выставлять CachedUpdates в
> true?

ну так, вроде, не сразу меняется, а в кэше. А потом по apply скопом..
так и отменять проще. И транзакция одна, лучше, наверное, чем много мелких

← →
Игорь Шевченко © (2011-01-27 13:10) [7]

Кайта читать. До полного и окончательного просветления. Оба тома. Наизусть.

← →
Игорь Шевченко © (2011-01-27 13:11) [8]

> update Table1 set Field1 = "ЗНАЧЕНИЕ" where Table1.id =
> Value

выкинуть

← →
12 © (2011-01-27 14:12) [9]

да это я к примеру
на самом деле там для этой же таблицы
так
это ж генератор :)
UPDATE BRANCH
SET
ID_BRANCH = :ID_BRANCH,
BNAME = :BNAME,
ID_FILIAL = :ID_FILIAL
WHERE
ID_BRANCH = :OLD_ID_BRANCH

но сути не меняет

> Кайта читать.

Вот взял кто-то, оба тома, и не несет, а кто - я забыл. Убил бы :)
если вспомнил..

← →
Игорь Шевченко © (2011-01-27 14:56) [10]

> да это я к примеру
> на самом деле там для этой же таблицы
> так
> это ж генератор :)
> UPDATE BRANCH
> SET
> ID_BRANCH = :ID_BRANCH,
> BNAME = :BNAME,
> ID_FILIAL = :ID_FILIAL
> WHERE
> ID_BRANCH = :OLD_ID_BRANCH

Выкинуть и читать Кайта

← →
12 © (2011-01-27 16:37) [11]

> Выкинуть и читать Кайта

так это генератор компонента был!
мне что же, совсем от ODAC отказаться теперь

ты скажи - будут проблемы при таком, указанном, подходе?

вот ситуация
0. пришел текстовый файл (xml, не важно),
1. script(или программа ли, не знаю, пока не решили) его анализирует и начинает апдейдить таблицы.
2. с моей программой(интерактивной) в это время работает кто-то, и правит те же таблицы, те же поля -

он не прервет этот, первый, автоматический процесс?
(Ни в коем случае нельзя этого делать)

Наверное ответ будет - смотря как написана программа2 и скрипт/программа1
2. Используются Toraquery, с CashedUpdates := true.
1. Ничего пока не используется, нет ее пока.

(есть мнение тупо проверить)

или вообще вопросы не те задаю?

12 © (27.01.11 16:37) [11]

> ты скажи - будут проблемы при таком, указанном, подходе?

Проблемы будут при непонимании работы сервера базы данных. Обязательно.

> или вообще вопросы не те задаю?

не те

> так это генератор компонента был!

в оракле нет термина "генератор компонента".

В оракле есть а) неблокирующее чтение б) блокировка записей при изменениях

если два сеанса примутся изменят одну и ту же запись указанным тобой способом, сервер им не помешает. Выиграет тот, чей commit будет последним. Что при этом будет с данными - русская рулетка.

← →
Паша (2011-01-29 05:50) [13]

> Желательно, что б пользователь не потерял много работы своей.

в этой штуке есть еще и компонента управления транзакциями. это на всякий случай

но, тут верно заметил Игорь насчет русской рулетки. и резонно встает вопрос, можно сказать, ребром - а оно надо?

если идет глобальный апдейт базы, то вопрос организационный - всех выгнать, закрыть сессии (пусть покурят) и апдейтить, с блокировкой естественно. ибо рискуешь потерять целостность данных.

← →
Паша (2011-02-06 13:29) [14]

во, кстати о птичках. в пятницу, буквально, у нас торопыги чуть по живому такой вот апгрейт не запустили, мною писаный. шустрики. пришлось внятно разъяснить, чем чревато. таки прониклись.

Паша (06.02.11 13:29) [14]

SELECT FOR UPDATE - наше все
http://www.itspecial.ru/theme/Problemy-sovmestnogo-dostupa-k-dannym-v-Oracle/10105/default.asp

← →
Кщд (2011-02-07 12:45) [16]

или dbms_lock
мне искренне непонятно, с какой целью из-за DML(DDL - совсем другой коленкор) делать базу однопользовательской

Oracle, ODAC и блокировки Найти похожие ветки