На этот раз - транзакции

← →
Ega23 © (2010-09-08 21:43) [40]

> можешь вклиниться между ? Нет ? Тогда ты неправ

Ты меня не так понял.
Впрочем, предлагаю не здесь и не сейчас, а 14-го в соответствующем месте. :)

← →
Petr V. Abramov © (2010-09-08 21:48) [41]

> а 14-го в соответствующем месте. :)
>

соберутся великие спецы по AS/400, жабе DB/2 :)

← →
Ega23 © (2010-09-08 21:51) [42]

> соберутся великие спецы по AS/400, жабе DB/2 :)

Если бы ты меня не продинамил, то мы бы с тобой это легко и непринуждённо обсудили бы. Прямо сегодня. Без проблем. Без жалости. Без пощады.

← →
Anatoly Podgoretsky © (2010-09-08 21:58) [43]

> Ega23 (08.09.2010 21:35:37) [37]

Логически это и есть, но это вроде и физически.

← →
Petr V. Abramov © (2010-09-08 21:58) [44]

> Ega23 © (08.09.10 21:51) [42]

один фиг оракл надо ставить на серьезных задачах, это раз, а я с тяжелым ящиком с инструментами на чёртановкую не поперся бы это два, че сам не позвонил это три.

← →
Игорь Шевченко © (2010-09-08 22:10) [45]

Ega23 © (08.09.10 21:43) [40]

> Ты меня не так понял.

Предлагаю принять за аксиому, что Update - это Update, единая и неделимая операция, а не Delete+Insert и не Insert+Delete.

> Впрочем, предлагаю не здесь и не сейчас, а 14-го в соответствующем
> месте. :)

Увы, не выйдет

← →
Ega23 © (2010-09-08 22:12) [46]

> Предлагаю принять за аксиому, что Update - это Update, единая
> и неделимая операция, а не Delete+Insert и не Insert+Delete.

Я вот это имел ввиду:

> Anatoly Podgoretsky © (08.09.10 21:58) [43]
>
> Логически это и есть, но это вроде и физически.

← →
Petr V. Abramov © (2010-09-08 22:14) [47]

> но это вроде и физически.

а вроде в мАскве не считается

← →
Anatoly Podgoretsky © (2010-09-08 22:20) [48]

> Предлагаю принять за аксиому, что Update - это Update, единая
> и неделимая операция, а не Delete+Insert и не Insert+Delete.
>

Например в Акцесс делается неявная транзакция, новые данные пишутся в новое место, потом старое освобождается, за счет этого и живуч. И чем это не удаление и вставка? И разрастание базы.
Вроде бы в MS SQL точно также. Кто то проводил иследования за страницами, новые данные в новое место. А MSSQL как и большинство серверов без транзакций не работают. Так и транзакцию легче сделать.

← →
jack128_ (2010-09-08 22:24) [49]

> Anatoly Podgoretsky © (08.09.10 22:20) [48]

для версионников такой подход - вообще единственно возможный.

← →
Petr V. Abramov © (2010-09-08 22:24) [50]

> Anatoly Podgoretsky © (08.09.10 22:20) [48]

> Кто то проводил иследования за страницами, новые данные
> в новое место.

скорей всего :) если новая нэ лезет на место старой, то и переносится. в некоторых базах переносится, что не влезает в блок, но там и контроль есть, сколько места резервировать под такие неприятности.

← →
Petr V. Abramov © (2010-09-08 22:25) [51]

> Petr V. Abramov © (08.09.10 22:24) [50]

в блоке резервировать

← →
Anatoly Podgoretsky © (2010-09-08 22:38) [52]

> jack128_ (08.09.2010 22:24:49) [49]

Ну так и считаем, что это удаление, ведь старой записи физически по
окончанию транзакции не остается.

Я собственно к чему. Вот в триггере есть таблица inserted. И есть deleted. А вот updated - чё-та нету...

Чего гадать, обратимся к первоисточнику

> В таблице deleted находятся копии строк, с которыми работали
> инструкции DELETE или UPDATE. При выполнении инструкции
> DELETE или UPDATE происходит удаление строк из таблицы триггера
> и их перенос в таблицу deleted. У таблицы deleted обычно
> нет общих строк с таблицей триггера.
>
> В таблице inserted находятся копии строк, с которыми работали
> инструкции INSERT или UPDATE. При выполнении транзакции
> вставки или обновления происходит одновременное добавление
> строк в таблицу триггера и в таблицу inserted. Строки таблицы
> inserted являются копиями новых строк таблицы триггера.
>
> Транзакция обновления аналогична выполнению операции удаления
> с последующим выполнением операции вставки; сначала старые
> строки копируются в таблицу deleted, а затем новые строки
> копируются в таблицу триггера и в таблицу inserted.

> Ega23 © (08.09.10 22:40) [53]
>
> Я собственно к чему. Вот в триггере есть таблица inserted.
> И есть deleted. А вот updated - чё-та нету...

это все потому что у insert-update-delete нету returning кляузы, у FB в 2.0 и то вроде б есть, а в этом мсскуле все ректально через триггер.

← →
Дмитрий Тимохов (2010-09-08 23:05) [57]

Я, возможно, невнимательно прочел, но что говорит profiler?
Нежели прямо такой и будет код: сначала delete, а потом insert и срубится по ошибке? Ну может правла кеширование клиентское?

Хотя к чему это я - СУБД то не тот, который я знаю.
Ну профайлер то должен быть!

> [29] Юрий Зотов © (08.09.10 17:45)
> В общем, причину так и не нашел
причина ясна. более менее, проверить только осталось. просто кое кто не хочет в нее верить...

у вас там не транзакция, а клиентская эмуляция. вот попробуй для проверки последовательность запросов типа (именно запросов, без оберток и их методов вроде StartTransaction и т.д.)
CREATE TABLE aaa (f1 INT PRIMARY KEY, f2 INT) INSERT INTO aaa (f1, f2) VALUES (1, 1) INSERT INTO aaa (f1, f2) VALUES (2, 2) INSERT INTO aaa (f1, f2) VALUES (3, 3) BEGIN TRANSACTION DELETE FROM aaa WHERE f1=2 INSERT INTO aaa (f1, f2) VALUES (4, 4) DELETE FROM aaa WHERE f1=3 INSERT INTO aaa (f1, f2) VALUES (5, 5) INSERT INTO aaa (f1, f2) VALUES (3, 3) INSERT INTO aaa (f1, f2) VALUES (2, 2) COMMIT TRANSACTION SELECT * FROM aaa

всегда работало. может синтаксис отличатся, но логика вряд ли.

На этот раз - транзакции Найти похожие ветки