Форум: "Базы";
Текущий архив: 2014.04.06;
Скачать: [xml.tar.bz2];
Вниз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. Ничего пока не используется, нет ее пока.
(есть мнение тупо проверить)
или вообще вопросы не те задаю?
← →
Игорь Шевченко © (2011-01-27 17:35) [12]12 © (27.01.11 16:37) [11]
> ты скажи - будут проблемы при таком, указанном, подходе?
Проблемы будут при непонимании работы сервера базы данных. Обязательно.
> или вообще вопросы не те задаю?
не те
> так это генератор компонента был!
в оракле нет термина "генератор компонента".
В оракле есть а) неблокирующее чтение б) блокировка записей при изменениях
если два сеанса примутся изменят одну и ту же запись указанным тобой способом, сервер им не помешает. Выиграет тот, чей commit будет последним. Что при этом будет с данными - русская рулетка.
← →
Паша (2011-01-29 05:50) [13]
> Желательно, что б пользователь не потерял много работы своей.
в этой штуке есть еще и компонента управления транзакциями. это на всякий случай
но, тут верно заметил Игорь насчет русской рулетки. и резонно встает вопрос, можно сказать, ребром - а оно надо?
если идет глобальный апдейт базы, то вопрос организационный - всех выгнать, закрыть сессии (пусть покурят) и апдейтить, с блокировкой естественно. ибо рискуешь потерять целостность данных.
← →
Паша (2011-02-06 13:29) [14]во, кстати о птичках. в пятницу, буквально, у нас торопыги чуть по живому такой вот апгрейт не запустили, мною писаный. шустрики. пришлось внятно разъяснить, чем чревато. таки прониклись.
← →
Игорь Шевченко © (2011-02-06 23:28) [15]Паша (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 - совсем другой коленкор) делать базу однопользовательской
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2014.04.06;
Скачать: [xml.tar.bz2];
Память: 0.48 MB
Время: 0.002 c