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

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

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

Когда лучше подтверждать транзакции [D5, IB6.x]

Страницы: 1 2 3 >
Тучудище © (2005-06-29 15:06:00)
Решил потихоньку осваивать IBX, в принципе все понятно с загадочным компонентом транзакция разобрался, одно только мне не совсем ясно наткнулся на статью в сети где четко и ясно написано что не стоит подтверждать транзакцию после добавления каждой новой записи(сбило с толку). Ув. мастера подскажите плиз, по какой логике надо действовать чтобы понять, когда ее нужно подтвердить...
Разберем пример обычного справочника
Пользователь добавил несколько запись
Вижу два варианта
1) Автоматическое подтверждение(Если после каждой вставки нельзя то когда)
2) Кнопка подтвердить транзакцию (сами знаете чем это грозит....)

Johnmen (2005-07-01 12:04:00) [1]
>kaif © (01.07.05 03:10) [48]

Да, после изменения метаданных надо делать переконнект, ведь они, метаданные, кешируются...

DiamondShark (2005-07-01 11:37:00) [2]
begin transaction create table Zzz(Id INT, Name CHAR(10)) insert into Zzz values(1,'qweqweqwe') select * from Zzz rollback transaction select * from Zzz (1 row(s) affected) Id Name ----------- ---------- 1 qweqweqwe (1 row(s) affected) Server: Msg 208, Level 16, State 1, Line 1 Invalid object name 'Zzz'.

Игорь Шевченко (2005-07-01 11:35:00) [3]
DiamondShark © (01.07.05 11:34) [54]

Спасибо, не знал.

DiamondShark (2005-07-01 11:34:00) [4]

> И при откате транзакции изменения, внесенные DDL-операторами
> тоже будут отменены ?

Да.

Игорь Шевченко (2005-07-01 11:30:00) [5]
DiamondShark © (01.07.05 11:26) [52]

> Например, в MSSQL DDL и DML могут смешиваться в одной транзакции.

И при откате транзакции изменения, внесенные DDL-операторами тоже будут отменены ?

DiamondShark (2005-07-01 11:26:00) [6]

> Не только в Oracle, но везде. Насколько я помню, это стандарт.

Вовсе нет.
Например, в MSSQL DDL и DML могут смешиваться в одной транзакции.

Desdechado (2005-07-01 11:15:00) [7]
2 kaif
это не типичный пример, а исключение
транзакция в обычном понимании - это манипуляция с данными, а не метаданными
понятно, что большинство серверов хранит метаданные как данные в системных таблицах, но это их внутреннее дело
нам, как пользователям, больше интересны именно обычные данные и обычные транзакции с ними

2 Игорь Шевченко
Не стандарт, а стремление к нему. Как верно указал kaif, в IB/FB большинство изменений метаданных можно проводить в одной транзакции. И, честно говоря, мне это нравится больше. А вот затыки с FK раздражают в таком контексте.

Игорь Шевченко (2005-07-01 09:59:00) [8]
Sergey13 © (01.07.05 09:22) [49]

> В Оракле DDL вообще вызывает неявный коммит

Не только в Oracle, но везде. Насколько я помню, это стандарт.

kaif © (01.07.05 03:10) [48]

> 6. Не использоать версии Firebird ниже 1.5 и InterBase
> ниже 6.5 и Yaffil ниже билда 877, если часто работаешь с
> метаданными

Э...странно. Я на Interbase 6.0.1 довольно неплохо себя чувствовал в похожей ситуации.

Sergey13 (2005-07-01 09:22:00) [9]
2[48] kaif © (01.07.05 03:10)
>Как ни прискорбно, но в IB желательно коммитить любое изменение метаданных (за редким исключением).
А что тут прискорбного? В Оракле DDL вообще вызывает неявный коммит. Да и вообще работа с метаданными в прикладной программе "на лету" дело очень тонкое и нетривиальное. И в 90% случаев говорит о непродуманности структуры (я немного знаком с твоей работой поэтому сразу оговорюсь, что ты, скорее всего, попадаешь в оставшиеся проценты 8-).

kaif (2005-07-01 03:10:00) [10]
Могу привести пример, когда даже делая связанные между собойизменения в базе приходится каждое изменение в отдельности коммитить. Как ни прискорбно, но в IB желательно коммитить любое изменение метаданных (за редким исключением). А некоторые изменения требуют не только коммита, но и монопольного доступа и даже реконнекта после внесения изменения и коммита. У меня программа много и плотно работает с метаданными и я прошел все круги ада, пока выработал ряд правил работы с метаданными IB.
1. Если после изменения метаданных (например, после создания новой таблицы) нужно изменить какие-то данные (например, вставить имя только что созданной таблицы в виде записи в какую-то свою "системную" таблицу), то необходимо эти действия делать в разных транзакциях и DDL-транзакцию (изменение метаданных) коммитить перед вставкой (DML-транзакцией).
2. До и после создания или удаления FOREIGN KEY нужно реконнектиться, иначе можно попасть в ситуацию "Table is in use" или "Index is in use".
3. Хранимые процедуры можно создавать/удалять безболезненно даже когда с системой работают пользователи.
4. Хранимые процедуры можно даже создать, использовать и уничтожить в пределах одной отдельной транзакции, не подтверждая ее.
5. Хранимые процедуры, вызываемые другими хранимыми процедурами могут продолжать работать в старых версиях даже после коммита транзакции, если не переконнектиться после изменения текста "вложенных процедур". Так что желательно избегать вложенности процедур или же тщательно разрабатывать "вложенные процедуры", чтобы часто не приходилось корректировать их текст.
6. Не использоать версии Firebird ниже 1.5 и InterBase ниже 6.5 и Yaffil ниже билда 877, если часто работаешь с метаданными.

Sergey13 (2005-06-30 17:39:00) [11]
2 [46] msguns © (30.06.05 17:32)
Удобство запихивания все таки мало перекликается собственно с транзакциями и их подтверждением. 8-)

msguns (2005-06-30 17:32:00) [12]
>Игорь Шевченко © (30.06.05 17:00) [45]
>Сережа, завязываем оффтопик

Так вот о транзакциях. Я вспомнил о ХП именно потому, что в них удобно запихивать сложные многоступенчатые изменения в базе, выполняемые как одно логически целое действо. Т.е. с т.зр. клиента удобно в одной транзакции запустить одну хранимку вместо того, чтобы выполнять кучу запросов, отслеживая транзакцию "ручками". При этом не малое значение играет и то, что алгоритм этих изменений может измениться. Подправив ХП, не надо вообще думать обо всем прочем.

Игорь Шевченко (2005-06-30 17:00:00) [13]
msguns © (30.06.05 16:39) [44]

Сережа, завязываем оффтопик, а то от транзакций здорово отклонились. Я к чему пример привел - к тому, что давай в форуме "Базы" использовать терминологию, относящуюся к базам, а не к бухгалтерии. А то мы нифига друг друга не поймем и будем до хрипоты спорить :)

msguns (2005-06-30 16:39:00) [14]
>Игорь Шевченко © (30.06.05 16:35) [43]

Ага, так ты залетевший банкир ?
Или банкующий летчик ?

Игорь Шевченко (2005-06-30 16:35:00) [15]
ANB © (30.06.05 16:26) [41]

BPS - Bank Settlement plan
ARC - Airlines reporting corporation

msguns (2005-06-30 16:27:00) [16]
>Игорь Шевченко © (30.06.05 16:01) [40]

Ах ты плеваться !?
Дуэль !!! На мясорубках !

ANB (2005-06-30 16:26:00) [17]

> А давай я тебе про сэмплинг или про клиринговые методы взаимозачетов
> или про BSP с ARC чего-нибудь расскажу интересное и познавательное
> ?
- раскажи, раскажи ! Интересно. Никогда таких абревиатур не слышал. Хоть определение дай. Только давайте в потрепаться переедем.

Игорь Шевченко (2005-06-30 16:01:00) [18]
msguns © (30.06.05 15:26) [38]

> если документ непроведенный, то любое его изменение НЕ приводит
> к изменению, например, текущих остатков. А если проведенный,
> то приводит. Но это так, к слову.

А давай я тебе про сэмплинг или про клиринговые методы взаимозачетов или про BSP с ARC чего-нибудь расскажу интересное и познавательное ?
Развелось бухгалтеров, понимаешь, плюнуть негде :)

Ты в следующий раз учти, что кроме бухгалтеров на свете еще другие люди существуют, знать не знающие про вашу терминологию.

Sergey13 (2005-06-30 15:54:00) [19]
2 msguns © & Игорь Шевченко ©
Похоже вы про разные откаты спорите. Один про откат документа другой про откат транзакции. Нет?
ЗЫ: Есть и еще значения у отката. 8-)

msguns (2005-06-30 15:26:00) [20]
>Игорь Шевченко © (30.06.05 14:52) [37]
>Я наверное тебя не так понял. Я думал, ты имеешь в виду, что вставка данных для такой транзакции тоже должна быть обернута в процедуру. А удалить проблем нету, обычно в триггере.

Откатить - это вовсе не удалить ! В триггер нельзя, ибо если документ непроведенный, то любое его изменение НЕ приводит к изменению, например, текущих остатков. А если проведенный, то приводит. Но это так, к слову.

Страницы: 1 2 3 >

Наверх

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