Когда лучше подтверждать транзакции

← →
Игорь Шевченко © (2005-06-30 16:01) [40]

msguns © (30.06.05 15:26) [38]

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

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

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

← →
ANB © (2005-06-30 16:26) [41]

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

← →
msguns © (2005-06-30 16:27) [42]

>Игорь Шевченко © (30.06.05 16:01) [40]

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

← →
Игорь Шевченко © (2005-06-30 16:35) [43]

ANB © (30.06.05 16:26) [41]

BPS - Bank Settlement plan
ARC - Airlines reporting corporation

← →
msguns © (2005-06-30 16:39) [44]

>Игорь Шевченко © (30.06.05 16:35) [43]

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

← →
Игорь Шевченко © (2005-06-30 17:00) [45]

msguns © (30.06.05 16:39) [44]

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

← →
msguns © (2005-06-30 17:32) [46]

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

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

← →
Sergey13 © (2005-06-30 17:39) [47]

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

← →
kaif © (2005-07-01 03:10) [48]

Могу привести пример, когда даже делая связанные между собой изменения в базе приходится каждое изменение в отдельности коммитить. Как ни прискорбно, но в 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-07-01 09:22) [49]

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

← →
Игорь Шевченко © (2005-07-01 09:59) [50]

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 довольно неплохо себя чувствовал в похожей ситуации.

← →
Desdechado © (2005-07-01 11:15) [51]

2 kaif
это не типичный пример, а исключение
транзакция в обычном понимании - это манипуляция с данными, а не метаданными
понятно, что большинство серверов хранит метаданные как данные в системных таблицах, но это их внутреннее дело
нам, как пользователям, больше интересны именно обычные данные и обычные транзакции с ними

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

← →
DiamondShark © (2005-07-01 11:26) [52]

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

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

DiamondShark © (01.07.05 11:26) [52]

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

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

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

Да.

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".

>kaif © (01.07.05 03:10) [48]

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

Когда лучше подтверждать транзакции Найти похожие ветки