07.11.2011 16:35, Arioch пишет:
В случае ошибки вероятно исключение всплывает наверх и проплывает через
код, который знает из каких строк он исходные значения взял.
Никакой код об этом не знает, ибо работает на основе BLR. А привязка BLR
к SQL существует лишь на уровне команд целиком.
--
В письме от Fri, 04 Nov 2011 13:14:10 +0400, Dmitry Yemanov
dim...@users.sf.net сообщал:
А при arithmetic error что выводить? Движок понятия не имеет на этот
момент, с какими строками/столбцами он работает. Код выполнения операций
контекстно отвязан от выборки данных, ему все равно с чем
04.11.2011 1:22, Arioch пишет:
А с какими данными это произошло?
В какой строке в каком столбце какой таблицы ???
Ну и запросы у вас (с)
а план запроса можно построить по BLR ?
Конечно. Но причем тут план?
select * from VIEW_VECTOR_COSINES
Arithmetic overflow or division by zero has
В письме от Wed, 02 Nov 2011 23:03:07 +0400, Алексей Вишняков
norrittmob...@googlemail.com сообщал:
Щас вам с таким предложением посоветуют пройти в трекер. И будут правы :)
предложат - пройду
но тут есть минимум два девела, кто инoгда может сразу влёт сказать фигня
вопрос или нет и не
ФБ всегда сообщает о контексте ошибки (строка/столбец), если это
произошло в процедуре. Если это не так - в трекер.
Но при этом не сообщается, где именно в отдельном PSQL-запросе произошла
ошибка. И я сильно не уверен, что такого стоит ожидать в ближайшем
будущем. Для нормальной диагностики
этом
показывают PK от таблицЫ, а не от вьюх.
Более сложный запрос:
merge into metrics m
using vector_angles_deg v on m.idx=v.metrics_idx
when matched then update set m.turn = v.angle;
Sorry, plan is unavailable for this statement...
Ну ладно, хемуль с ним с планом, хотя раньше был
В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov
dim...@users.sf.net сообщал:
22.10.2011 9:21, Arioch пишет:
Хорошая штука UPDATE с JOIN'ом :-)
Чем MERGE не устроил?
Вот
Нарвался в данных на совпадение двух точек подряд. Отсюда нуевая длина и
деление на ноль. В одной
:
Хорошая штука UPDATE с JOIN'ом :-)
Чем MERGE не устроил?
Вот
Нарвался в данных на совпадение двух точек подряд. Отсюда нуевая длина и
деление на ноль. В одной строке из множества.
И все это внутри процедуры, хотя это и не так важно.
Недостаток в том, что сообщив про деление на ноль, FB это
В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov
dim...@users.sf.net сообщал:
Хорошая штука UPDATE с JOIN'ом :-)
Чем MERGE не устроил?
Упс
SQL-2008
Пора кэш обновлять :-)
--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
22.10.2011 9:21, Arioch пишет:
Хорошая штука UPDATE с JOIN'ом :-)
Чем MERGE не устроил?
--
Дмитрий Еманов
Firebird поддерживают обычный синтаксис оператора
UPDATE. СУБД MS SQL также поддерживает синтаксис оператора UPDATE,
в котором выполняется соединение (join) и производится обновление одной
из таблиц соединения. Можно думать об этом как об условии WHERE
на стероидах. Если такая функция очень нужна
Куда рыть?
в триггера?
Andrew пишет:
Привет.
столкнулся с такой бедой.
Есть одна табличка. в эксперте набираю update x set y=z where c = p
эксперт рапортует что все ок.
Делаю селект - изменения не прошли.
commit ?
Аи бл#$% вопрос сниматся, лопахнулся, у меня там ешё прибуилдини
на TCP/IP и там похоже что criticalsection чтото блокирует ...
ФБ в порядке :)
Regards
Janex
Почти :-)
Триггер старый-забытый срабатывал :-)
Sorry
On 15 окт, 14:33, Janex jane...@gmail.com wrote:
Аи бл#$% вопрос сниматся, лопахнулся, у меня там ешё прибуилдини
на TCP/IP и там похоже что criticalsection чтото блокирует ...
ФБ в порядке :)
Regards
Janex
Yurij ...
Переношу базу с 1.5.4 на 2.1.1. Сделал бэкап-ресторе, выполняю
обновление чарсета метаданных. И после
SQL select * from rdb$fix_metadata('WIN1251');
SQL commit;
вылазит такое сообщение:
Statement failed, SQLCODE = -151
attempted update of read-only column
Кто-нибудь может
On Jun 12, 4:30 pm, Khorsun Vlad hv...@optima.com.ua wrote:
Yurij ...
attempted update of read-only column
Кто-нибудь может подсказать, где искать причину ошибки?
В кривых AFTER триггерах, присваивающих в NEW и\или OLD, и\или
кривых BEFORE DELETE(INSERT), триггерах, присваивающих в
Yurij ...
On Jun 12, 4:30 pm, Khorsun Vlad wrote:
Yurij ...
attempted update of read-only column
Кто-нибудь может подсказать, где искать причину ошибки?
В кривых AFTER триггерах, присваивающих в NEW и\или OLD, и\или
кривых BEFORE DELETE(INSERT), триггерах, присваивающих в NEW(OLD).
Ага
On Jun 12, 4:51 pm, Khorsun Vlad hv...@optima.com.ua wrote:
Yurij ...
В кривых AFTER триггерах, присваивающих в NEW и\или OLD, и\или
кривых BEFORE DELETE(INSERT), триггерах, присваивающих в NEW(OLD).
Ага, поищу. Но почему на метаданных и почему только после коммита -
это для меня
12.06.2009 17:24, Yurij пишет:
Переношу базу с 1.5.4 на 2.1.1. Сделал бэкап-ресторе, выполняю
обновление чарсета метаданных. И после
SQL select * from rdb$fix_metadata('WIN1251');
SQL commit;
АСРК?
С уважением,
Стариков Алексей
On Jun 12, 7:09 pm, St. Alex s...@pisem.net wrote:
12.06.2009 17:24, Yurij пишет:
SQL select * from rdb$fix_metadata('WIN1251');
SQL commit;
АСРК?
Ничего в голову, кроме а почему вы спрашиваете? не приходит :)
Кузнецов Евгений ...
Доброго времени суток!
On 12 нояб, 23:11, Vlad Khorsun wrote:
Из-за того, что после удаленя версии (сборка мусора при чтении) апдейт сразу же
пишет новую версию на ту же страницу, возникает цикл в графе зависимостей
страниц,
разрешить который можно только записью
Ясное дело, что во втором случае writes на порядок больше,
но почему так получается? Update медленнее собирает мусор, чем Select?
Из-за того, что после удаленя версии (сборка мусора при чтении) апдейт сразу
же
пишет новую версию на ту же страницу, возникает цикл в графе зависимостей
Доброго времени суток!
On 12 нояб, 23:11, Vlad Khorsun wrote:
Из-за того, что после удаленя версии (сборка мусора при чтении) апдейт
сразу же
пишет новую версию на ту же страницу, возникает цикл в графе зависимостей
страниц,
разрешить который можно только записью страницы на диск. При
Доброго времени суток!
Khorsun Vlad пишет:
fetches, reads, *writes*
Вот данные для 2.1.1 CS, FW ON
Скрипт 1
Start Transaction: consistency
no_auto_undo
ExecSQL:
update Test_table1
set data1 = data1 || '111'
where data1 '0'
PLAN (TEST_TABLE1 INDEX (TEST_TABLE1_DATA1
Доброго времени суток!
On 10 нояб, 00:29, Dmitri Kuzmenko wrote:
GCPolicy какое значение установлено?
Рекомендую поменять на альтернативные и проверить.
Извините, забыл написать - на CS смотрел. Надо попробовать
и на SS погонять.
Ну и на всякий случай
Кузнецов Евгений ...
Доброго времени суток!
update Test_table1
set data1 = data1 || '111'
where data1 '0';
COMMIT;
select Count(*) from Test_table1;
COMMIT;
update Test_table1
set data1 = data1 || '111'
where data1 '0';
COMMIT;
всегда (на 2.1.1 и 2.5.0.21329) быстрее
Кузнецов Евгений ...
Помню, спасибо. А чем, кстати, закончился Ваш застарелый спор с
Владом?
Наши победили
--
Хорсун Влад
Кузнецов Евгений ...
Доброго времени суток!
On 10 нояб, 10:22, Khorsun Vlad wrote:
Иногда имеет смысл посмотреть на статистику выполнения запросов :-D
Вы purge_count имеете в виду? Хорошо, вечером гляну.
Хотя все равно странно - в каждом случае БД создавалась с нуля.
fetches, reads,
Hello, Евгений!
Кузнецов Евгений wrote:
update Test_table1
select Count(*) from Test_table1;
update Test_table1
всегда (на 2.1.1 и 2.5.0.21329) быстрее, чем
update Test_table1
COMMIT;
update Test_table1
причем при включенном FW - где-то в 2 раза
GCPolicy какое значение
Доброго времени суток!
On 10 нояб, 10:22, Khorsun Vlad wrote:
Иногда имеет смысл посмотреть на статистику выполнения запросов :-D
Вы purge_count имеете в виду? Хорошо, вечером гляну.
Хотя все равно странно - в каждом случае БД создавалась с нуля.
--
С уважением, Евгений
Доброго времени суток!
update Test_table1
set data1 = data1 || '111'
where data1 '0';
COMMIT;
select Count(*) from Test_table1;
COMMIT;
update Test_table1
set data1 = data1 || '111'
where data1 '0';
COMMIT;
всегда (на 2.1.1 и 2.5.0.21329) быстрее, чем
update
ну вот и получит 30 мая, видимо.
Boltik Evgeny wrote:
отправил тебе писмо 30/05/08 на kdv1 ты его получил?
--
Кочмин Александр
отправил тебе писмо 30/05/08 на kdv1 ты его получил?
FB 1.5.5, FW=ON, Win2003
Делаем UPDATE, статистика:
175000 updates, 855 writes, 8 seconds
делаем rollback и тот же update:
175000 updates, 35 writes, 4 minutes
Получается, что если при первом проходе несколько апдейтов, попадающих
на одну страницу, скидывались на диск 1 раз (это мои
Khorsun Vlad wrote:
Если роллбек выполнился быстро, это значит что dead версии остались на
диске. Теперь update должен сначала удалить dead версию, и только потом
писать свою новую. Такая операция часто приводит к циклическим зависимостям
между страницами (careful write однако). Посему
Konstantin R. Beliaev wrote:
А если после rollback сделать select count(*) + commit - это поможет?
щас попробую :-)
Вроде помогает
:)
Hello, Konstantin!
Konstantin R. Beliaev wrote:
FB 1.5.5, FW=ON, Win2003
Делаем UPDATE, статистика:
175000 updates, 855 writes, 8 seconds
скорее всего количество версий превышает ситуацию, когда
сервер может сам отменить изменения и превратить rollback
в commit. Таким образом имеем
А если после rollback сделать select count(*) + commit - это поможет?
щас попробую :-)
Вроде помогает
:)
До поры до времени.
У меня один раз такая помощь (на полуторке) чуть чуть меньше чем трое суток
длилась :)
Ночное задание едва уложилось в максимальные 72 часа.
Правда это был явно
Александр Свириденков ...
В RN написано что нерекурсивные CTE могут иcпользоваться в подзапросах
Update/Insert/Delete.
А что насчет рекурсивных? И какой тогда синтаксис?
На
with recursive a as (...) update ... ругается
Такой синтаксис не поддерживается
на update ... where
On 29 нояб, 11:31, Vlad Khorsun [EMAIL PROTECTED] wrote:
Лучший способ - MERGE :
Спасибо! Сейчас попробую
Выяснились забавные вещи.
Если использовать параметры вида field=:param
то последний IBExpert выполнять такой запрос отказывается, говорит
Column unknown param
Заменяем :param на ?, получаем новую ошибку - data type unknown.
Делаем cast(? as ...), получаем SQLDA missing or incorrect version, or
Александр Свириденков ...
А примеры чего? Что параметры без cast не работают? Так любой запрос c
merge using with recursive c параметрами это покажет, причем на
параметры
как в with recursive части ругается, так и в on ..
Похоже на багу в MERGE, исправим.
А вот если задавать пар-ры
А насчет число измененных записей - посмотрел, FIB виноват но
косвенно. Дело в том что сервер возвращает для Merge как в примере тип
SQLInsert, хотя там только Update.
Соответсвенно и RowsAffected берет из вставленных а не измененных.
Даже не знаю кто тут больше виноват
Привет, Vlad!
Вы пишешь 29 ноября 2007:
VK Гм, MERGE может и вставлять, и апдейтить записи.
VK Так что что тут возвращать в кач-ве типа statement'а - я не знаю.
Опять цепляемся за мифическую совместимость?
Ну не нужно этой мимикрии - ...брюки превращаются, превращаются брюки... (С).
Alex Cherednichenko ...
Привет, Vlad!
Вы пишешь 29 ноября 2007:
VK Гм, MERGE может и вставлять, и апдейтить записи.
VK Так что что тут возвращать в кач-ве типа statement'а - я не знаю.
Опять цепляемся за мифическую совместимость?
Ну не нужно этой мимикрии - ...брюки превращаются,
В RN написано что нерекурсивные CTE могут иcпользоваться в подзапросах
Update/Insert/Delete.
А что насчет рекурсивных? И какой тогда синтаксис?
На
with recursive a as (...) update ... ругается
на update ... where .. in (with recursive ...) тоже
äÌÑ ÚÁÒÅÇÉÓÔÒÉÒÏ×ÁÎÎÙÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ Delphi 2007 for Win32 É C++Builder 2007
for Win32 ×ÙÌÏÖÅÎ update #2. óËÁÞÁÔØ update #2 ÍÏÖÎÏ ÎÁ ÓÔÒÁÎÉÃÅ
ÚÁÒÅÇÉÓÔÒÉÒÏ×ÁÎÎÏÇÏ ÐÏÌØÚÏ×ÁÔÅÌÑ Delphi 2007 (
http://www.codegear.com/downloads/regusers/delphi ) ÉÌÉ C++Builder 2007 (
http://www.codegear.com/downloads
Респект, Усем!
Есть таблица описывающая дерево папок :
CREATE TABLE CALC_FOLDERS (
FOLDERID SMALLINT NOT NULL,
PARENTID SMALLINT NOT NULL,
NAME VARCHAR(50),
POS SMALLINT
);
ALTER TABLE CALC_FOLDERS ADD CONSTRAINT PK_CALC_FOLDERS PRIMARY KEY (FOLDERID);
Со
Доброго времени суток!
Oleg Prosvetov wrote:
Как мне одним апдейтом заполнить поле POS относительно поля PARENTID, чтобы
стало так ?:
Примерно так
update CALC_FOLDERS c
set pos = (select Count(*) from CALC_FOLDERS c1
where c1.parentid = c.parentid and c1.folderid = c.folderid),
но это
Привет всем еще раз.
Добавил поддержку UPDATE IR INSERT ... RETURNING. Сознание
захлебнулось от щастья.
Тесты с RETUNING отработали на ура. Ну, думаю, все в ажуре.
Тут черт дернул написать без RETUNING. Последовательность такая
- очистка таблицы
- UPDATE OR INSERT. Rows Affected вернул 1. Ура
Dmitri Kuzmenko ...
вообще ТАК ПОЛОЖЕНО. Другое дело, что у нас чтение в RC не атомарное.
Что было доказано тестами год-полтора назад
(вставки с commit пакетами, и запрос типа sum или count в RC)
Буду занудствовать : атомарность к чтению никак не относится. Это
св-во тр-ции. Правильно
Dmitri Kuzmenko wrote:
чудной ты. Бита - это ж символ, хоть и вещественный. А символом
нешто орудуют? :-)
Ты знаешь, мне тут бубен подарили, настоящий, турецкий. На днях
постукивал, в задумчивости вокруг плавающего AV в одной из своих прог.
Помогло, додумался :)
--
Regards. Ded.
On Tue, 26 Jun 2007 12:51:03 +0400, Ded [EMAIL PROTECTED] wrote:
Ты знаешь, мне тут бубен подарили, настоящий, турецкий. На днях
постукивал, в задумчивости вокруг плавающего AV в одной из своих прог.
Помогло, додумался :)
0FF:
Сдаётся мне , что турецкий - ненастоящий бубен. Откуда там
Hello, WildSery!
You wrote on Tue, 26 Jun 2007 15:21:12 +0400:
Ты знаешь, мне тут бубен подарили, настоящий, турецкий.
На днях постукивал, в задумчивости вокруг плавающего AV
в одной из своих прог. Помогло, додумался :)
W 0FF:
W Сдаётся мне , что турецкий - ненастоящий бубен. Откуда
Качановский Дмитрий wrote:
если эти две транзакции начнут изменение одновременно, что произойдет?
Эксперимент тебе поможет.
Из ветки я понял, что непонимание достаточно глубокое.
Откатятся ВСЕ изменения сделанные этим update.
ÔÏÇÄÁ ÐÅÒÅÞÉÔÁÊ ÅÝÅ ÐÁÒÕ-ÔÒÏÊËÕ ÒÁÚ.
ÄÌÉÎÎÏ×ÁÔÁ ÄÌÑ ÍÁÎÔÒÙ :)
ËÁÛÁ Õ ÔÅÂÑ × ÇÏÌÏ×Å, ÅÓÌÉ ÔÅÂÑ ÉÎÔÅÒÅÓÕÅÔ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÏÓÔØ ÏÂÎÏ×ÌÅÎÉÑ
ÚÁÐÉÓÅÊ UPDATE-ÏÍ. ïÎ ÏÂÎÏ×ÌÑÅÔ ÚÁÐÉÓÉ ÐÏÛÔÕÞÎÏ.
ïÔÂÏÒ ÉÄÅÔ ËÁË ÏÂÙÞÎÏ - ÂÅÚ ÉÎÄÅËÓÁ, ÞÅÒÅÚ ÉÎÄÅËÓ, É Ô.Ð.
ÂÅÚ ÉÎÄÅËÓÁ ÉÌÉ ÞÅÒÅÚ ÉÎÄÅËÓ ÚÁÐÉÓÉ ×ÓÅ ÒÁ×ÎÏ
ÅÓÌÉ ÜÔÉ Ä×Å ÔÒÁÎÚÁËÃÉÉ ÎÁÞÎÕÔ ÉÚÍÅÎÅÎÉÅ ÏÄÎÏ×ÒÅÍÅÎÎÏ, ÞÔÏ ÐÒÏÉÚÏÊÄÅÔ?
×ÙÒ×ÁÌ ÆÒÁÚÕ É ËÏÎÔÅËÓÔÁ???
Ñ ÓÐÒÁÛÉ×ÁÌ ÐÒÏ ÏÐÅÒÁÔÏÒ update Á ÎÅ ÐÒÏ ÔÒÁÎÚÁËÃÉÉ
éÚ ×ÅÔËÉ Ñ ÐÏÎÑÌ, ÞÔÏ ÎÅÐÏÎÉÍÁÎÉÅ ÄÏÓÔÁÔÏÞÎÏ ÇÌÕÂÏËÏÅ.
ÕÇÕ, ÇÄÅ-ÔÏ ÎÁ ÕÒÏ×ÎÅ ËÏÄÁ
ïÔËÁÔÑÔÓÑ ÷óå ÉÚÍÅÎÅÎÉÑ ÓÄÅÌÁÎÎÙÅ ÜÔÉÍ update
Качановский Дмитрий wrote:
Откатятся ВСЕ изменения сделанные этим update.
откатиться может транзакция, а оператор может выполниться или нет, причем
строго над всем множеством записей
Словоблудие. С точки зрения середины апдейта - изменения именно откатятся.
--
Дмитрий Еманов
ÓÏÂÓÔ×ÅÎÎÏ ÎÁ ÜÔÏÔ ×ÏÐÒÏÓ ÍÎÅ ÕÖÅ ÏÔ×ÅÔÉÌÉ - ×ÙÐÏÌÎÑÅÔÓÑ ÐÏÛÔÕÞÎÏ, Á
ÓÌÅÄÏ×ÁÔÅÌØÎÏ ËÏÎÆÌÉËÔÙ ×ÏÚÍÏÖÎÙ, Á ÓÌÅÄÏ×ÁÔÅÌØÎÏ ÏÔËÁÔÙ
ÅÝÅ ÏÓÔÁÌÓÑ ÍÁÌÅÎØËÉÊ ×ÏÐÒÏÓÉË, ÏÔ ÏÂÝÅÇÏ (ÎÁÓËÏÌØËÏ ÁÔÏÍÁÒÅÎ update)
Á ÎÁÓËÏÌØËÏ ÁÔÏÍÁÒÅÎ ×ÏÔ ÔÁËÏÊ
update some_table set counter = counter + 1 where id = :id
Ô.Å
óÌÏ×ÏÂÌÕÄÉÅ. ó ÔÏÞËÉ ÚÒÅÎÉÑ ÓÅÒÅÄÉÎÙ ÁÐÄÅÊÔÁ - ÉÚÍÅÎÅÎÉÑ ÉÍÅÎÎÏ ÏÔËÁÔÑÔÓÑ.
ÓÌÏ×ÏÂÌÕÄÉÅ?... ... ÓÏÇÌÁÓÅÎ
ÎÏ ÅÓÌÉ ÏÐÅÒÁÔÏÒ ÁÔÏÍÁÒÅÎ, ÔÏ ÌÏÇÉÞÎÏ ÐÒÅÄÐÏÌÏÖÉÔØ, ÞÔÏ ÅÓÌÉ ÏÐÅÒÁÔÏÒ ÒÅÛÉÌ
ÄÁ Ñ ÂÕÄÕ ÍÅÎÑÔØ ÜÔÉ ÄÁÎÎÙÅ ÔÏ ÎÉËÁËÁÑ ÇÎÉÄÁ ÕÖÅ ÎÅ ÓÍÏÖÅÔ ÐÒÏÔÉÓÎÕÔØÓÑ É
ÐÏÍÅÛÁÔØ ÅÍÕ × ÜÔÏÍ
ÓÏÂÓÔ×ÅÎÎÏ ÎÁ
Качановский Дмитрий wrote:
а насколько атомарен вот такой
Выше уже говорили, что термин атомарность имеет несколько другое значение.
update some_table set counter = counter + 1 where id = :id
т.е. насколько гарантировано, что если оператор прочитал данные и решил их
менять, какова
Качановский Дмитрий [EMAIL PROTECTED] wrote in message news:[EMAIL
PROTECTED]
без обсуждения параметров транзакции задавать некорректно, это я понимаю)
ТОгда зачем задавать вопрос?! :-) (см. в сторону снепшотов, select for update)
2. оптимизируется и получение данных для update происходит в
÷ÙÛÅ ÕÖÅ ÇÏ×ÏÒÉÌÉ, ÞÔÏ ÔÅÒÍÉÎ ÁÔÏÍÁÒÎÏÓÔØ ÉÍÅÅÔ ÎÅÓËÏÌØËÏ ÄÒÕÇÏÅ
ÚÎÁÞÅÎÉÅ.
ËÁË ÖÅ ÄÒÕÇÏÊ??
×ÏÔ äë ÐÉÛÅÔ
Ñ ÚÁÍÅÞÕ, ÞÔÏ ÁÔÏÍÁÒÎÏÓÔØ update ÜÔÏ ÏÂÎÏ×ÉÔ update ×ÓÅ ÚÁÐÉÓÉ,
ÐÏÐÁÄÁÀÝÉÅ ÐÏÄ ÕÓÌÏ×ÉÅ, ÉÌÉ ÐÒÉ ÏÂÌÏÍÅ - ÎÉ ÏÄÎÏÊ
-
ÐÏÐÒÏÂÕÀ ÕÐÒÏÓÔÉÔØ - ÏÂÎÏ×ÉÔØ ×ÓÅ ÉÌÉ ÎÉÞÅÇÏ - ÐÁ×ÉÌØÎÏ?
Ó ÄÒÕÇÏÊ
выборку в полном объеме и без задержек
(wait/no_wait)
В rec_version - да, он просто зачитает коммиченное. В no_rec_version -
см.выше.
правильно ли я понимаю, что update, выбирая поштучно записи для модификации
не гарантирует, что выборка будет получена в полном объеме и в том виде в
каком они были
Качановский Дмитрий wrote:
но если оператор атомарен, то логично предположить, что если оператор решил
да я буду менять эти данные то никакая гнида уже не сможет протиснуться и
помешать ему в этом
Короче, хочу блокировочник с упреждающей блокировкой, но без
блокировки ;)
--
Regards.
в полном объеме и без задержек
(wait/no_wait)
бред какой то.
правильно ли я понимаю, что update, выбирая поштучно записи для модификации
не гарантирует, что выборка будет получена в полном объеме и в том виде в
каком они были на старте оператора при тех же параметрах тразакций что и
раньше
ÂÅÚ ÏÂÓÕÖÄÅÎÉÑ ÐÁÒÁÍÅÔÒÏ× ÔÒÁÎÚÁËÃÉÉ ÚÁÄÁ×ÁÔØ ÎÅËÏÒÒÅËÔÎÏ, ÜÔÏ Ñ ÐÏÎÉÍÁÀ)
ôïÇÄÁ ÚÁÞÅÍ ÚÁÄÁ×ÁÔØ ×ÏÐÒÏÓ?! :-) (ÓÍ. × ÓÔÏÒÏÎÕ ÓÎÅÐÛÏÔÏ×, select for
update)
ÎÕ ÎÅÚÎÁÀ Ñ ËÁË ÐÒÁ×ÉÌØÎÏ ÜÔÏÔ ×ÏÐÒÏÓ ÚÁÄÁÔØ, ×ÏÔ É ËÒÕÞÕÓØ ×ÓÅ ×ÏËÒÕÇ ÄÁ
ÏËÏÌÏ
update ÏÐÅÒÁÔÏÒ ÓÌÏÖÎÙÊ, Ô.Å. ÅÇÏ ×ÙÐÏÌÎÅÎÉÅ ÐÒÏÉÓÈÏÄÉÔ
Dmitry Yemanov wrote:
for select id
from some_table
order by id
do
update some_table set counter = counter + 1 where id = :id
как она воспринимается сервером
1. получение курсора и последовательность самостоятельных вызовов update
Именно так.
Мне каатся он о другом. Мне
определяется уровнем изолированности.
Оператор select/update/delete в момент своего старта вообще
не имеет понятия какие записи он увидит.
Это ты версионник начинаешь путать с блокировочником, который
сначала блокирует, а потом уже делает.
В версионнике видимость можно определить только при чтении
Качановский Дмитрий
внутри сервера, когда вот такое обнаруживается. Наверное правильнее было
бы послать меня читать исходники, но прошу этого не делать, я их все равно
не пойму.
Именно так.
я исходников не читал, но все это выяснил для себя путем одновременного
запуска двух экземпляров
Качановский Дмитрий wrote:
я замечу, что атомарность update это обновит update все записи,
попадающие под условие, или при обломе - ни одной
-
попробую упростить - обновить все или ничего - павильно?
Правильно.
с другой стороны про селект в статье о транзакциях (я уже приводил эту
ÐÒÅÄÐÏÌÁÇÁÅÍÙÊ ÚÁÐÒÏÓ ÎÁ ÉÚÍÅÎÅÎÉÅ:
update some_table
set
counter = counter + 1
where id in (ÐÅÒÅÞÅÎØ ÚÁÉÓÅÊ, ËÏÔÏÒÙÅ ÎÁÄÏ ÉÚÍÅÎÉÔØ)
ÎÁÐÒÉÍÅÒ Õ ÔÒÁÚÁËÃÉÉ ÔÒ1 ÎÁÂÏÒ ÚÎÁÞÅÎÉÊ (1, 2, 3)
Á Õ ÔÒÁÎÚÁËÃÉÉ ÔÒ2 ÎÁÂÏÒ (3, 2, 1)
ÅÓÌÉ ÜÔÉ Ä×Å ÔÒÁÎÚÁËÃÉÉ ÎÁÞÎÕÔ ÉÚÍÅÎÅÎÉÅ ÏÄÎÏ×ÒÅÍÅÎÎÏ, ÞÔÏ ÐÒÏÉÚÏÊÄÅÔ
Качановский Дмитрий ...
Выше уже говорили, что термин атомарность имеет несколько другое
значение.
как же другой??
От так. Бываетъ
вот ДК пишет
я замечу, что атомарность update это обновит update все записи,
попадающие под условие, или при обломе - ни одной
-
попробую
Hello, Дмитрий!
Качановский Дмитрий wrote:
update оператор сложный, т.е. его выполнение происходит в несколько этапов
(получение записи/получение полей/сообщение всем счас буду менять/
изменение/сообщение всем изменил)
где ты это взял, про сообщения? update/delete тупо МОДИФИЦИРУЕТ
запись
ÕÆÆ
ÂÏÌØÛÏÅ ÓÐÁÓÉÂÏ ×ÓÅÍ ÚÁ ÏÔ×ÅÔÙ
ÎÅ ÔÏ ÞÔÏ ÂÙ Õ ÍÅÎÑ ÂÏÌØÛÅ ×ÏÐÒÏÓÏ× ÎÅ ÏÓÔÁÌÏÓØ, ÎÏ ÔÅÐÅÒØ ÐÏÎÁÄÏÂÉÔÓÑ ×ÒÅÍÑ
ÞÔÏ ÂÙ ×ÓÅ ÜÔÏ ÐÒÏÞÉÔÁÔØ É ÏÓÏÚÎÁÔØ :)
2äë
ÞÅÓÔÎÏÅ ÓÌÏ×Ï ÞÉÔÁÌ ×ÓÅ ÞÔÏ ÒÅËÏÍÅÎÄÕÅÛØ, É ÄÁÖÅ ÎÅÓËÏÌØËÏ ÒÁÚ.
ÎÏ ÏÂÅÝÁÀ: × ÂÕÄÕÝÅÍ ÏÂÑÚÁÔÅÌØÎÏ ÅÝÅ ÂÕÄÕ ÐÅÒÅÞÉÔÙ×ÁÔØ
:)
ÄÁ ×ÏÔ É ÅÝÅ
Hello, Дмитрий!
Качановский Дмитрий wrote:
примечание: кроме транзакций атомарным считается также и выполнение
операторов. Например SELECT в режиме read committed видит только те записи,
которые были committed другими транзакциями или изменены текущей на момент
своего старта (т.е. execute).
ÐÒÅÄÐÏÌÁÇÁÅÍÙÊ ÚÁÐÒÏÓ ÎÁ ÉÚÍÅÎÅÎÉÅ:
update some_table
set
counter = counter + 1
where id in (ÐÅÒÅÞÅÎØ ÚÁÉÓÅÊ, ËÏÔÏÒÙÅ ÎÁÄÏ ÉÚÍÅÎÉÔØ)
ÎÁÐÒÉÍÅÒ Õ ÔÒÁÚÁËÃÉÉ ÔÒ1 ÎÁÂÏÒ ÚÎÁÞÅÎÉÊ (1, 2, 3)
Á Õ ÔÒÁÎÚÁËÃÉÉ ÔÒ2 ÎÁÂÏÒ (3, 2, 1)
ÅÓÌÉ ÜÔÉ Ä×Å ÔÒÁÎÚÁËÃÉÉ ÎÁÞÎÕÔ ÉÚÍÅÎÅÎÉÅ ÏÄÎÏ×ÒÅÍÅÎÎÏ, ÞÔÏ ÐÒÏÉÚÏÊÄÅÔ?
--
ó Õ
реально нарваться на дидлок
предполагаемый запрос на изменение:
update some_table
set
counter = counter + 1
where id in (перечень заисей, которые надо изменить)
например у тразакции тр1 набор значений (1, 2, 3)
а у транзакции тр2 набор (3, 2, 1)
если эти две транзакции начнут изменение
Доброго времени суток!
Качановский Дмитрий wrote:
одновременно менять пересекающиеся наборы данных крайне высока, вот и
возникает вопрос насколько реально нарваться на дидлок
read_committed, wait пробовали?
С уважением, Евгений.
ÏÄÎÏ×ÒÅÍÅÎÎÏ ÍÅÎÑÔØ ÐÅÒÅÓÅËÁÀÝÉÅÓÑ ÎÁÂÏÒÙ ÄÁÎÎÙÈ ËÒÁÊÎÅ ×ÙÓÏËÁ, ×ÏÔ É
×ÏÚÎÉËÁÅÔ ×ÏÐÒÏÓ ÎÁÓËÏÌØËÏ ÒÅÁÌØÎÏ ÎÁÒ×ÁÔØÓÑ ÎÁ ÄÉÄÌÏË
read_committed, wait ÐÒÏÂÏ×ÁÌÉ?
ÓÏÂÓÔ×ÅÎÎÏ ÇÏ×ÏÒÑ, ÒÅÛÉÌÉ ÐÅÒÅÄ ÔÅÍ ËÁË ÐÒÏÂÏ×ÁÔØ, ÓÎÁÞÁÌÁ ÓÐÒÏÓÉÔØ
ÜÍÕÌÉÒÏ×ÁÔØ ÐÏÄÏÂÎÕÀ ÓÉÔÕÁÃÉÀ ÄÏÓÔÁÔÏÞÎÏ ÓÌÏÖÎÏ, ×ÏÔ ÐÏÔÏÍÕ É ÒÅÛÉÌ
т.е. разницы что в одном опереаторе производить изменения, что во многих (т.е.
на каждую запись по отдельному оператору update) абсолютно нету?
не понял юмора... ты говоришь о двух транзакциях, сервер в этом случае
тупо смотрит была ли ситуация, что одна и та же запись изменялась (поле
ему
ÐÒÅÄÐÏÌÁÇÁÅÍÙÊ ÚÁÐÒÏÓ ÎÁ ÉÚÍÅÎÅÎÉÅ:
update some_table
set
counter = counter + 1
where id in (ÐÅÒÅÞÅÎØ ÚÁÉÓÅÊ, ËÏÔÏÒÙÅ ÎÁÄÏ ÉÚÍÅÎÉÔØ)
ÎÁÐÒÉÍÅÒ Õ ÔÒÁÚÁËÃÉÉ ÔÒ1 ÎÁÂÏÒ ÚÎÁÞÅÎÉÊ (1, 2, 3)
Á Õ ÔÒÁÎÚÁËÃÉÉ ÔÒ2 ÎÁÂÏÒ (3, 2, 1)
ÅÓÌÉ ÜÔÉ Ä×Å ÔÒÁÎÚÁËÃÉÉ ÎÁÞÎÕÔ ÉÚÍÅÎÅÎÉÅ ÏÄÎÏ×ÒÅÍÅÎÎÏ, ÞÔÏ
Hello, Дмитрий!
Качановский Дмитрий wrote:
update some_table
set
counter = counter + 1
where id in (перечень заисей, которые надо изменить)
например у тразакции тр1 набор значений (1, 2, 3)
а у транзакции тр2 набор (3, 2, 1)
мда. where id in это
where id = 1 or id = 2 or id = 3
почему
что - нет
я замечу, что атомарность update это обновит update все записи,
попадающие под условие, или при обломе - ни одной.
вот в чем атомарность. А не в порядке обновления записей.
Никакого порядка обновления, как и вообще порядка в реляционных
множествах, нет.
--
Dmitri Kouzmenko
Á ×ÔÏÒÏÊ ÐÒÏ ÐÅÒÅÓÅËÁÀÝÉÅÓÑ ÍÎÏÖÅÓÔ×Á (ÓÏ×ÐÁÄÁÀÝÉÅ ËÁË ÞÁÓÔÎÙÊ ÓÌÕÞÁÊ) ×
ÏÄÎÏÍ ÏÐÅÒÁÔÏÒÅ
Ñ ÚÁÍÅÞÕ, ÞÔÏ ÁÔÏÍÁÒÎÏÓÔØ update ÜÔÏ ÏÂÎÏ×ÉÔ update ×ÓÅ ÚÁÐÉÓÉ,
ÐÏÐÁÄÁÀÝÉÅ ÐÏÄ ÕÓÌÏ×ÉÅ, ÉÌÉ ÐÒÉ ÏÂÌÏÍÅ - ÎÉ ÏÄÎÏÊ.
ÏÂÌÏÍ ÎÅ ÓÏ×ÓÅÍ ÕÄÁÞÎÙÊ ÔÅÒÍÉÎ ÄÌÑ ÐÏÑÓÎÉÎÉÑ ÒÁÂÏÔÙ ÒÅÌÑÃÉÏÎÎÙÈ óõâä
:))
ÐÏÎÑÔÎÏ ÞÔÏ ÅÓÌÉ
вот мой вопрос собсно об этом
каким образом выполняется update множества записей, какой из двух вариантов
ближе?
вариант 1.
- читаем перву запись с подходящими условиями, изменяем
- читаем вторую, изменяем
- читаем третью, натыкаемся на то что другая транзакция ее изменила, ждем...
ждем
×ÁÒÉÁÎÔ 1.
- ÞÉÔÁÅÍ ÐÅÒ×Õ ÚÁÐÉÓØ Ó ÐÏÄÈÏÄÑÝÉÍÉ ÕÓÌÏ×ÉÑÍÉ, ÉÚÍÅÎÑÅÍ
- ÞÉÔÁÅÍ ×ÔÏÒÕÀ, ÉÚÍÅÎÑÅÍ
- ÞÉÔÁÅÍ ÔÒÅÔØÀ, ÎÁÔÙËÁÅÍÓÑ ÎÁ ÔÏ ÞÔÏ ÄÒÕÇÁÑ ÔÒÁÎÚÁËÃÉÑ ÅÅ ÉÚÍÅÎÉÌÁ,
ÖÄÅÍ... ÖÄÅÍ.. ÖÄÅÍ...
ÜÔÏÔ.
ÔÏÇÄÁ Õ ÍÅÎÑ ×ÏÐÒÏÓ Ë ÒÁÚÒÁÂÏÔÞÉËÁÍ, ÎÁÓËÏÌØËÏ ÜÔÏ ÌÏÇÉÞÎÏ Ó ÔÏÞËÉ ÚÒÅÎÉÑ
ÒÅÌÑÃÉÏÎÎÙÈ ÍÎÏÖÅÓÔ×.
множеством (естественно не блокируя его на время ожидания) и выполнить
это было понятно, но чего ты этим хочешь добится? в общем случае
проблему deadlock ты не решил, поскольку в одной транзакции можно
использовать несколько update. ну да, в твоем конкретном случаее это бы
решило твою проблему
Hello, Дмитрий!
Качановский Дмитрий wrote:
2. (wait) дождаться когда будет можно будет выполнить операцию над всем
множеством (естественно не блокируя его на время ожидания) и выполнить
сначала внимательно прочитай:
www.ibase.ru/devinfo/ibtrans.htm
потом
www.ibase.ru/devinfo/pslock.htm
ÜÔÏ ÂÙÌÏ ÐÏÎÑÔÎÏ, ÎÏ ÞÅÇÏ ÔÙ ÜÔÉÍ ÈÏÞÅÛØ ÄÏÂÉÔÓÑ? × ÏÂÝÅÍ ÓÌÕÞÁÅ
ÄÏÂÉÔÓÑ ÈÏÞÕ ÏÄÎÏÇÏ - ÐÏÎÑÔØ ËÁË ÒÁÂÏÔÁÅÔ update (ÐÏËÁ ÔÏËÏ update) × FB.
ÎÕ É ÚÁÏÄÎÏ, ÞÔÏ ÒÁÚÒÁÂÏÔÞÉËÉ ÄÕÍÁÀÔ ÐÏ ÜÔÏÍÕ ÐÏ×ÏÄÕ (× ÓÍÙÓÌÅ ÞÔÏ ÓÞÉÔÁÅÔÓÑ
ÎÏÒÍÁÌØÎÁÍ ÐÏ×ÅÄÅÎÉÅÍ, Á ÞÔÏ ÎÕ ËÏÇÄÁ-ÎÉÂÕÄØ ÓÄÅÌÁÅÍ ÐÒÁ×ÉÌØÎÅÅ)
ÐÒÏÂÌÅÍÕ
ÐÏÄÏÖÄÁÔØ ÄÏ ÒÅÛÅÎÉÑ ËÏÎËÕÒÅÎÔÁ - commit ÉÌÉ rollback.
ÅÓÌÉ ÈÏÞÅÛØ ÞÔÏÂÙ ÚÁÐÒÏÓÙ ÎÅ ÐÅÒÅÓÅËÁÌÉÓØ - ÉÓÐÏÌØÚÕÊ
ÂÌÏËÉÒÏ×ÁÎÉÅ ÔÁÂÌÉà ÃÅÌÉËÏÍ.
×ÏÔ ÂÌÏËÉÒÏ×ÁÎÉÑ ÔÁÂÌÉà ÃÅÌÉËÏÍ ÈÏÔÅÌÏÓØ ÂÙ ÉÚÂÅÖÁÔØ.
ÓÏÂÓÔ×ÅÎÎÏ ×ÏÐÒÏÓ ÂÙÌ ÎÅ × ÔÒÁÎÚÁËÃÉÑÈ É ÂÌÏËÉÒÏ×ËÁÈ, Á ÉÍÅÎÎÏ × update. ×
ËÁËÏÊ ÐÏÓÌÅÄÏ×ÁÔÅÌØÎÏÓÔÉ
Hello, Дмитрий!
Качановский Дмитрий wrote:
перечитал в очередной раз... дополнительного просветления сознания не
обнаружил.. наверное достиг максимального уровня...
:))
тогда перечитай еще пару-тройку раз.
собственно вопрос был не в транзакциях и блокировках, а именно в update. в
какой
ðÒÉ×ÅÔ
update commodity set SalePrices=DeliveryPrice,DeliveryPrice=SalePrices
where DeliveryPriceSalePrices
þÔÏ ÂÕÄÅÔ × DeliveryPrice? óÔÁÒÏÅ SalePrices ÉÌÉ ÎÏ×ÏÅ
FB2
äÍÉÔÒÉÊ
Dmitry Lendel ...
Привет
update commodity set SalePrices=DeliveryPrice,DeliveryPrice=SalePrices
where DeliveryPriceSalePrices
Что будет в DeliveryPrice? Старое SalePrices или новое
Вот для того, чтобы не гадать и не зависеть от версий сервера,
хорошие мальчики так не пишут
where DeliveryPriceSalePrices
into :LIDKey,:LDeliveryPrice,:LSalePrice
do
Update Commodity Set SalePrices=:ldeliveryprice,DeliveryPrice=:LSalePrice
where IDKey=:LIDKey;
end
ÎÏ ÓÔÁÌÏ ÉÎÔÅÒÅÓÎÏ, ÐÏÔÏÍÕ ÓÐÒÏÓÉÌ.
äÍÉÔÒÉÊ
Hello, Dmitry!
Dmitry Lendel wrote:
update commodity set SalePrices=DeliveryPrice,DeliveryPrice=SalePrices
where DeliveryPriceSalePrices
Что будет в DeliveryPrice? Старое SalePrices или новое
баян. saleprices будет равно deliveryprice.
хотя по стандарту не должно.
--
Dmitri Kouzmenko
äÌÑ ÚÁÒÅÇÉÓÔÒÉÒÏ×ÁÎÎÙÈ ÐÏÌØÚÏ×ÁÔÅÌÅÊ Delphi 2007 for Win32 ×ÙÌÏÖÅÎ Update #1
(ÐÏÓÌÅ ÅÇÏ ÕÓÔÁÎÏ×ËÉ × AboutBox ×ÅÒÓÉÑ 11.0.2709.7128). ïÎ ÄÏÓÔÕÐÅÎ × IDE
ÞÅÒÅÚ ÆÕÎËÃÉÀ Automatic Update É ÄÌÑ ÓËÁÞËÉ ÎÁ ÓÔÒÁÎÉÃÅ ÚÁÒÅÇÉÓÔÒÉÒÏ×ÁÎÎÏÇÏ
ÐÏÌØÚÏ×ÁÔÅÌÑ.
http://downloads.codegear.com/default.aspx?productid
óËÏÒÏ ×ÙÊÄÅÔ Delphi 2007 Update 1 × ËÏÔÏÒÏÍ ÉÓÐÒÁ×ÌÅÎÏ ÂÏÌÅÅ 300 ÂÁÇÏ×,
ÐÏÄÒÏÂÎÅÅ ÓÍ. List of QC reports (http://dn.codegear.com/article/36589)
P.S. åÓÌÉ ËÔÏ ÎÅ ÓÍÏÔÒÅÌ InterBase Security Updates
(http://dn.codegear.com/article/36564)
http://www.delphiplus.org - ÅÖÅÄÎÅ×ÎÙÅ ÎÏ×ÏÓÔÉ
И тишина. Неужто никто не планирует использовать UPDATE OR INSERT и не
может решить по какому критерию лучше определять есть такая запись или нет?
Результаты 1 - 100 из 207 matches
Mail list logo
