Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Oracle, ODAC и блокировки [D7]

12 © (2011-01-27 08:55:00)
Скажите, а если TOraQuery из набора ODAC
поставить CashedUpdates := true, не будет блокировки при прогоне скриптов массовых updatах админом БД?

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

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

Не бабахнет?

Кщд (2011-02-07 12:45:00) [1]
или dbms_lock
мне искренне непонятно, с какой целью из-за DML(DDL - совсем другой коленкор) делать базу однопользовательской

Игорь Шевченко (2011-02-06 23:28:00) [2]
Паша (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-06 13:29:00) [3]
во, кстати о птичках. в пятницу, буквально, у нас торопыги чуть по живому такой вот апгрейт не запустили, мною писаный. шустрики. пришлось внятно разъяснить, чем чревато. таки прониклись.

Паша (2011-01-29 05:50:00) [4]

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

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

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

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

Игорь Шевченко (2011-01-27 17:35:00) [5]
12 © (27.01.11 16:37) [11]

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

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

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

не те

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

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

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

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

12 (2011-01-27 16:37:00) [6]

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

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

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

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

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

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

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

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

Игорь Шевченко (2011-01-27 14:56:00) [7]

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

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

12 (2011-01-27 14:12:00) [8]
да это я к примеру
на самом деле там для этой же таблицы
так
это ж генератор :)
UPDATE BRANCH
SET
ID_BRANCH = :ID_BRANCH,
BNAME = :BNAME,
ID_FILIAL = :ID_FILIAL
WHERE
ID_BRANCH = :OLD_ID_BRANCH

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

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

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

Игорь Шевченко (2011-01-27 13:11:00) [9]

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

выкинуть

Игорь Шевченко (2011-01-27 13:10:00) [10]
Кайта читать. До полного и окончательного просветления. Оба тома. Наизусть.

12 (2011-01-27 11:32:00) [11]

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

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

12 (2011-01-27 10:51:00) [12]
в основном такого типа

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

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

Кщд (2011-01-27 10:46:00) [13]
>12 © (27.01.11 10:03) [2]
>если будет CashedUpdates := true
>блокировка как устанавливается?
какой запрос?

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

12 (2011-01-27 10:05:00) [14]
написал программу(почти), где CashedUpdates := true,
программа гриды, поля показывает - пользователь их правит. Id не трогает.

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

12 (2011-01-27 10:03:00) [15]
если будет CashedUpdates := true
блокировка как устанавливается?

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

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

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

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

Кщд (2011-01-27 09:42:00) [16]
12 © (27.01.11 08:55)
Любой DML устанавливает блокировку. Соответственно, update - в частности.
В чем вопрос?

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »