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

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

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

Не бабахнет?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


выкинуть

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

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


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

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

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


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

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

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

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

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

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

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

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

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

12 ©   (27.01.11 16:37) [11]


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


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


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


не те


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


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

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

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

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

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

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

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

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

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

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

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