Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 25   вперед  Ctrl
 Re: Нужна помощь  [new]
MasterZiv
Member

Откуда: Питер
Сообщений: 34709

Bogdanov Andrey wrote:

> И кто вас учил в триггерах делать откат?

А почему бы и нет ? Чего напали -то на человека ?
В MSSQL не было исключений долгое время (сейчас кажется добавили уже)
и такое по

> Управлять транзакцией из тригера в общем-то идеологически неверно.
> Конечно, бывают случаи, когда это может пригодиться, но такие случаи
> крайне редки. Закрывать или откатывать транзакцию должен тот, кто ее
> открывал.

Ну, вообще-то триггер считался всегда частью того DML-я, который
его запускает. Поскольку, в случае autocommit = on этот statement
и запускает транзакцию, то очень даже логично (по вашей логике)
откатывать транзакцию в триггере.

Если autocommit = off, то

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

Это - лишь один из подходов к управлению транзакций, причём приемлимый
только в системах, поддерживающих исключения. Если исключений нет,
то этот ваш подход просто не работает.
Так что не пудрите мозги неокрепшему в деле СУБД товарищу, ему и так
тяжело.

> Если триггер "считает", что один оператор выполнять нельзя, то он просто
> должен честно сообщить об этом вызвавшему приложению, то есть поднять
> исключение. Сам оператор при этом, естественно, не выполнится, а уж как
> приложение отреагирует на исключение - это дело приложения.

А вот это - традиционная "дырка" в таких рассуждениях.
Ты реализуешь в БД какую-то логику, которая нарушается
и это фиксируется выбросом исключения. Но приложение,
поймав это исключение, может всё-таки транзакцию закоммитить.
И зачем тогда мы парились и что-то проверяли в триггере,
если эта проверка обходится ? Т.е. как минимум надо
иметь вложенные транзакции или savepoint-ы, чтобы неправильные
изменения можно было бы откатить без отката всей остальной транзакции.
А не во всех СУБД есть такое.

Posted via ActualForum NNTP Server 1.4

25 авг 08, 11:27    [6104324]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11551
SergSuper
Bogdanov Andrey
Если триггер "считает", что один оператор выполнять нельзя, то он просто должен честно сообщить об этом вызвавшему приложению, то есть поднять исключение. Сам оператор при этом, естественно, не выполнится, а уж как приложение отреагирует на исключение - это дело приложения.

Это только Ваша точка зрения.
А я к примеру считаю что триггеры обеспечивают целостность базы и транзакцию, которая целостность нарушает они должны обрывать, независимо от того что там думает приложение.
Тр-ция ничего не нарушает, она не умеет Умеет - оператор, который и будет откачен поднятым в триггере исключением.
Если MSSQL до 2005-го года не умел обрабатывать исключения, это его личные проблемы Но не стоит учить плохому других. Хорошо спроектированный софт всегда разбит на слои, максимально изолированные друг от друга. Откат тр-ции не в том слое, который её создавал, есть грубейшее нарушение этой изоляции.
25 авг 08, 11:28    [6104332]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
SergSuper
А я к примеру считаю что триггеры обеспечивают целостность базы и транзакцию, которая целостность нарушает они должны обрывать, независимо от того что там думает приложение.
Триггер "живет" в рамках одного оператора и видит только то, что данный оператор нарушает целостность. Приложение, выполняющее данный оператор вполне может, получив сообщение о нарушении целостности, заменить данный оператор чем-то другим и успешно завершить транзакцию. Если же приложение считает, что без данного оператора завершить транзакцию нельзя, то оно эту транзакцию и откатит. Именно приложение формирует тот набор операторов, которые оно включает в одну транзакцию и именно оно знает насколько данный набор операторов взаимосвязан.
25 авг 08, 11:34    [6104374]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
MasterZiv

Ну, вообще-то триггер считался всегда частью того DML-я, который
его запускает.
Вот именно и "сбой" в триггере это сбой в том сfмом DML, а не во всей транзакции.

MasterZiv
Поскольку, в случае autocommit = on этот statement
и запускает транзакцию, то очень даже логично (по вашей логике)
откатывать транзакцию в триггере.

Если autocommit = on, то говорить о транзакциях вооще смысла нет, так как в этом случае транзакция и оператор почти одно и то же. И невыполнение оператора означает то же, что и откат транзакции.

MasterZiv
А вот это - традиционная "дырка" в таких рассуждениях.
Ты реализуешь в БД какую-то логику, которая нарушается
и это фиксируется выбросом исключения. Но приложение,
поймав это исключение, может всё-таки транзакцию закоммитить.
А вот тут можно поподробнее? В чем дырка? Все что было до выброса исключения приложение и так имело возможность закоммитить. То есть сделав в триггере вместо исключения откат мы ничуть не спасем кривую логику. Если мы на уровне БД хотим гарантировать, что некая группа операторов всегда исполняется совместно, то это надо не откатами в триггерах решать, а созданием хранимых процедур. В противном случае приложение всегда сможет эти операторы по одному выполнить.
25 авг 08, 11:43    [6104433]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
hvlad
SergSuper
Bogdanov Andrey
Если триггер "считает", что один оператор выполнять нельзя, то он просто должен честно сообщить об этом вызвавшему приложению, то есть поднять исключение. Сам оператор при этом, естественно, не выполнится, а уж как приложение отреагирует на исключение - это дело приложения.

Это только Ваша точка зрения.
А я к примеру считаю что триггеры обеспечивают целостность базы и транзакцию, которая целостность нарушает они должны обрывать, независимо от того что там думает приложение.
Тр-ция ничего не нарушает, она не умеет Умеет - оператор, который и будет откачен поднятым в триггере исключением.
Если MSSQL до 2005-го года не умел обрабатывать исключения, это его личные проблемы Но не стоит учить плохому других. Хорошо спроектированный софт всегда разбит на слои, максимально изолированные друг от друга. Откат тр-ции не в том слое, который её создавал, есть грубейшее нарушение этой изоляции.

Если FB не умеет откатывать транзацию на сервере, это его личные проблемы Но не стоит учить плохому других. Хорошо спроектированный софт всегда разбит на слои, максимально изолированные друг от друга. Но откат тр-ции в любом слое обрывает всю транзакцию и нет смысла следить откаты по слоям

Bogdanov Andrey
Триггер "живет" в рамках одного оператора и видит только то, что данный оператор нарушает целостность. Приложение, выполняющее данный оператор вполне может, получив сообщение о нарушении целостности, заменить данный оператор чем-то другим и успешно завершить транзакцию. Если же приложение считает, что без данного оператора завершить транзакцию нельзя, то оно эту транзакцию и откатит. Именно приложение формирует тот набор операторов, которые оно включает в одну транзакцию и именно оно знает насколько данный набор операторов взаимосвязан.

У Вас подход что приложение должно следить за базой. Мне он не нравится.
Если же приложение считает, что без данного оператора завершить транзакцию нельзя а если приложение решило иначе? прощай целостность базы?



И, господа, брость ваш безапелляционный тон. Я рад за вас что вы считаете что только ваш путь истинный, но считайтесь с теми кто думает иначе
25 авг 08, 12:17    [6104659]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
SergSuper
У Вас подход что приложение должно следить за базой. Мне он не нравится.

Вы видимо не понимаете моего подхода. Как раз в вашем подходе никто не следит за базой.

SergSuper
Если же приложение считает, что без данного оператора завершить транзакцию нельзя а если приложение решило иначе? прощай целостность базы?

Если база спроектирована так, что несколько операторов могут нарушить ее целостность, то никакой откат в триггере не поможет целостность спасти.

SergSuper
И, господа, брость ваш безапелляционный тон. Я рад за вас что вы считаете что только ваш путь истинный, но считайтесь с теми кто думает иначе
Одно дело - думать иначе, а другое дело - аргументировать. Пожалуйста, привелите пример при котором откат в триггере обеспечивает целостность базы.
25 авг 08, 13:12    [6104943]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Bogdanov Andrey
Если база спроектирована так, что несколько операторов могут нарушить ее целостность, то никакой откат в триггере не поможет целостность спасти.


Мне кажется, Вы передергиваете. Я сторонник подхода реализации бизнес-логики на стороне сервера и противник (за исключением редких случаев) управления транзакциями с "клиента".

Если вся логика реализована на сервере и даже с откатами транзакций в триггерах, то серверной стороне практически все-равно, кто к нему будет обращаться и как он это будет делать.
25 авг 08, 13:28    [6105019]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Bogdanov Andrey
Одно дело - думать иначе, а другое дело - аргументировать. Пожалуйста, привелите пример при котором откат в триггере обеспечивает целостность базы.


Под целостностью базы следует понимать не только то, что можно обеспечить декларативными средствами, но и целостность с точки зрения бизнес-логики, когда, например, операция списания средств при определенных условиях не должна увести клиентский счет в "минус".
25 авг 08, 13:30    [6105039]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Если вся логика реализована на сервере и даже с откатами транзакций в триггерах, то серверной стороне практически все-равно, кто к нему будет обращаться и как он это будет делать.
Да, все равно, если рассматривать весь сервер, как один слой. Но на мой взгляд, это все-таки два слоя - слой хранения данных и слой управления данными.
В общем-то, можно считать это вопросом вкуса, но если считать весь сервер, как один слой, то использовать триггера вообще нет надобности - прозрачность кода снижается, производительность тоже не выигрывает.
25 авг 08, 13:33    [6105055]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Bogdanov Andrey
Одно дело - думать иначе, а другое дело - аргументировать. Пожалуйста, привелите пример при котором откат в триггере обеспечивает целостность базы.


Под целостностью базы следует понимать не только то, что можно обеспечить декларативными средствами, но и целостность с точки зрения бизнес-логики, когда, например, операция списания средств при определенных условиях не должна увести клиентский счет в "минус".
Я это прекрасно понимаю. Но не вижу каким образом откат в триггере поможет данную целостность соблюсти.
25 авг 08, 13:34    [6105059]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Bogdanov Andrey
Я это прекрасно понимаю. Но не вижу каким образом откат в триггере поможет данную целостность соблюсти.


Гм... Если операции по счету фиксируются в таблице "Операции по счету клиента", а текущий остаток лежит в таблице "Остаток на счет", и есть еще таблица с "Видами счетов клиента", где указывается может ли счет уйти в минус, то почему бы в триггере на INSERT\UPDATE первой таблицы не проверить, что получиться при подтверждении этой операции во второй и на основании данных третьей не откатить транзакцию в случие ухода в минус, сохранив т.о. целостность данных с точки бизнес-логики?!
25 авг 08, 13:40    [6105096]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Гм... Если операции по счету фиксируются в таблице "Операции по счету клиента", а текущий остаток лежит в таблице "Остаток на счет", и есть еще таблица с "Видами счетов клиента", где указывается может ли счет уйти в минус, то почему бы в триггере на INSERT\UPDATE первой таблицы не проверить, что получиться при подтверждении этой операции во второй и на основании данных третьей не откатить транзакцию в случие ухода в минус, сохранив т.о. целостность данных с точки бизнес-логики?!
А как этот триггер помешает сделать update таблицы остатков и загнать туда отрицательное значение?
25 авг 08, 13:47    [6105144]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

SergSuper

Но откат тр-ции в любом слое обрывает всю транзакцию и нет смысла
следить откаты по слоям

Простейший пример: я стартую транзакцию, вставляю запись, ещё одну,
провожу апдейт первой записи ссылкой на вторую, коммичу транзакцию.
Можешь предсказать результат этой последовательности, если триггер при
вставке первой записи откатит транзакцию?

Posted via ActualForum NNTP Server 1.4

25 авг 08, 13:47    [6105153]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Bogdanov Andrey
А как этот триггер помешает сделать update таблицы остатков и загнать туда отрицательное значение?


Триггер м.б. повешен на любую таблицу. Я привел пример "навскидку", который бы показывал, что проверка условия в триггере и откат транзакции не такая уж и утопия.
25 авг 08, 13:50    [6105172]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov

Простейший пример: я стартую транзакцию, вставляю запись, ещё одну,
провожу апдейт первой записи ссылкой на вторую, коммичу транзакцию.
Можешь предсказать результат этой последовательности, если триггер при
вставке первой записи откатит транзакцию?


Интересно, а что тут можно предсказывать (для MS SQL), если откат транзакции в триггере не даст выполнится ни одно инструкции в баче, после инструкции, вызвавшей срабатывание триггера?!
25 авг 08, 13:52    [6105182]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Bogdanov Andrey
А как этот триггер помешает сделать update таблицы остатков и загнать туда отрицательное значение?


Триггер м.б. повешен на любую таблицу. Я привел пример "навскидку", который бы показывал, что проверка условия в триггере и откат транзакции не такая уж и утопия.
Ваш пример "навскидку" не позволяет обеспечить целостность данных. И я пока совершенно не понимаю, как этот пример доработать так, чтобы обеспечивал. И причем здесь откат в триггере также совершенно не понимаю. Достаточно raiseerror.
25 авг 08, 13:52    [6105183]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Dimitry Sibiryakov

Простейший пример: я стартую транзакцию, вставляю запись, ещё одну,
провожу апдейт первой записи ссылкой на вторую, коммичу транзакцию.
Можешь предсказать результат этой последовательности, если триггер при
вставке первой записи откатит транзакцию?


Интересно, а что тут можно предсказывать (для MS SQL), если откат транзакции в триггере не даст выполнится ни одно инструкции в баче, после инструкции, вызвавшей срабатывание триггера?!
А вот это непонятно. Если я делаю insert, в это время срабатывает триггер, который делает откат, то второй insert сделать уже нельзя? Это правда так и работает?
25 авг 08, 13:56    [6105211]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Bogdanov Andrey
Ваш пример "навскидку" не позволяет обеспечить целостность данных. И я пока совершенно не понимаю, как этот пример доработать так, чтобы обеспечивал. И причем здесь откат в триггере также совершенно не понимаю. Достаточно raiseerror.


А что, если Ваш RAISERROR будет некому обработать?!

Bogdanov Andrey
А вот это непонятно. Если я делаю insert, в это время срабатывает триггер, который делает откат, то второй insert сделать уже нельзя? Это правда так и работает?


Интересно, что тут непонятного. Я специально указал, что речь идет о баче.


If a ROLLBACK TRANSACTION is issued in a trigger:

-All data modifications made to that point in the current transaction are rolled back, including any that were made by the trigger.

-The trigger continues executing any remaining statements after the ROLLBACK statement. If any of these statements modify data, the modifications are not rolled back. No nested triggers are fired by the execution of these remaining statements.

-None of the statements in the batch after the statement that fired the trigger are executed.


-A ROLLBACK in a trigger closes and deallocates all cursors that were declared and opened in the batch containing the statement that fired the trigger. This includes cursors declared and opened in stored procedures called by the batch that fired the trigger. Cursors declared in a batch prior to the batch that fired the trigger are only closed, except that STATIC or INSENSITIVE cursors are left open if:
-CURSOR_CLOSE_ON_COMMIT is set OFF.

-The static cursor is either synchronous, or a fully populated asynchronous cursor.

Ваши инсерты в одном баче?
25 авг 08, 14:04    [6105264]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
hvlad
Member

Откуда:
Сообщений: 11551
SergSuper
hvlad
SergSuper
Это только Ваша точка зрения.
А я к примеру считаю что триггеры обеспечивают целостность базы и транзакцию, которая целостность нарушает они должны обрывать, независимо от того что там думает приложение.
Тр-ция ничего не нарушает, она не умеет Умеет - оператор, который и будет откачен поднятым в триггере исключением.
Если MSSQL до 2005-го года не умел обрабатывать исключения, это его личные проблемы Но не стоит учить плохому других. Хорошо спроектированный софт всегда разбит на слои, максимально изолированные друг от друга. Откат тр-ции не в том слое, который её создавал, есть грубейшее нарушение этой изоляции.

Если FB не умеет откатывать транзацию на сервере, это его личные проблемы Но не стоит учить плохому других. Хорошо спроектированный софт всегда разбит на слои, максимально изолированные друг от друга. Но откат тр-ции в любом слое обрывает всю транзакцию и нет смысла следить откаты по слоям
FB умеет откатывать транзацию на сервере, если она там начата. Речь о том, что откат оператора != откат тр-ции, попробуйте это понять.
Отслеживать (обрабатывать) исключение в промежуточных слоях не только не вредно, но иногда даже полезно. Хотя и не обязательно, если верхний слой корректно его обрабатывает.
Проблема в том, что начинающие (или просто ленивые) программисты не понимают важности изоляции слоёв, смешивают их (по незнанию или от лени) и в результате рано или поздно платят за это. А MS часто поощряет это, за что и справедливо критикуется. Им плюс, конечно, что они в конце-концов вводят нормальные инструменты, но ох как долго этого приходится ждать...

SergSuper
Bogdanov Andrey
Триггер "живет" в рамках одного оператора и видит только то, что данный оператор нарушает целостность. Приложение, выполняющее данный оператор вполне может, получив сообщение о нарушении целостности, заменить данный оператор чем-то другим и успешно завершить транзакцию. Если же приложение считает, что без данного оператора завершить транзакцию нельзя, то оно эту транзакцию и откатит. Именно приложение формирует тот набор операторов, которые оно включает в одну транзакцию и именно оно знает насколько данный набор операторов взаимосвязан.

У Вас подход что приложение должно следить за базой.
Нет. Подход заключается в соблюдении изоляции разных слоёв ПО.

SergSuper
Мне он не нравится.
О ужас

SergSuper
Если же приложение считает, что без данного оператора завершить транзакцию нельзя а если приложение решило иначе? прощай целостность базы?
а) Почему ? Оператор, нарушивший целостность, откачен. Вызывающий слой должен обработать эту ситуацию. В крайнем случае - откатом тр-ции.
б)Если разные слои не согласованны, то ой

SergSuper
И, господа, брость ваш безапелляционный тон. Я рад за вас что вы считаете что только ваш путь истинный, но считайтесь с теми кто думает иначе
Не нужно искать наездов там, где их нет. И жизнь станет приятнее :)
25 авг 08, 14:12    [6105329]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Bogdanov Andrey
Ваш пример "навскидку" не позволяет обеспечить целостность данных. И я пока совершенно не понимаю, как этот пример доработать так, чтобы обеспечивал. И причем здесь откат в триггере также совершенно не понимаю. Достаточно raiseerror.


А что, если Ваш RAISERROR будет некому обработать?!

Значит оно дойдет до "пользователя".
Вас ведь не удивляет, что "аналогичный" raise вызванный нарушением декларативного ограничения тоже надо обрабатывать.
Вы предлагаете использовать два разных механизма поддержания целостности - один декларативный (и с обработкой raise в приложении), а другой - основанный на откатах в триггерах. Или вы декларативными ограничениями не пользуетесь?
25 авг 08, 14:18    [6105375]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

pkarklin
Ваши инсерты в одном баче?

Нет, разумеется. Они (предположительно) в одной транзакции.
Которая "вдруг" оказывается откаченной в самый разгар работы.

Posted via ActualForum NNTP Server 1.4

25 авг 08, 14:21    [6105395]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Bogdanov Andrey
Значит оно дойдет до "пользователя".


Дошел он до пользователя, и что?! А если пользователь забил на него. Целостность бд нарушена?

Bogdanov Andrey
Вас ведь не удивляет, что "аналогичный" raise вызванный нарушением декларативного ограничения тоже надо обрабатывать.


В большинстве случаев это обрабатывание - показ соответствующего ссобшения об ошибке, ибо транзакции с нарушением декларативных ограничений откатываются сервером автоматически (в подавляющем большинств случаев).

Bogdanov Andrey
Вы предлагаете использовать два разных механизма поддержания целостности - один декларативный (и с обработкой raise в приложении), а другой - основанный на откатах в триггерах. Или вы декларативными ограничениями не пользуетесь?


Интересно, на основании каких моих слов Вы сделали такое заключение? Про "обработку" в приложении я уже писАл. Осталось только добиться и от недекларативных ограничейний (реализуемых, например, на триггерах) таких же поведенческих характеристик, дабы в "приложении" не было никакой обработки кроме вывода сообщения об ошибке.
25 авг 08, 14:28    [6105444]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
Dimitry Sibiryakov

pkarklin
Ваши инсерты в одном баче?

Нет, разумеется. Они (предположительно) в одной транзакции.
Которая "вдруг" оказывается откаченной в самый разгар работы.


Почему "вдруг"?! ROLLBACK в триггере, даже без явного RAISERROR приведет к исключительной ситуации 3609: The transaction ended in the trigger. The batch has been aborted.

Вам надо всего навсего обработать эту исключительную ситуацию.
25 авг 08, 14:31    [6105474]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
В большинстве случаев это обрабатывание - показ соответствующего ссобшения об ошибке, ибо транзакции с нарушением декларативных ограничений откатываются сервером автоматически (в подавляющем большинств случаев).
Это правда? То есть если в таблице остатков висит ограничение check (balance > 0), то insert в такую таблицу с отрицательным значением откатит всю транзакцию? Я не настолько хорошо знаком с mssql, но мне такое поведение кажется невероятным.
25 авг 08, 14:33    [6105502]     Ответить | Цитировать Сообщить модератору
 Re: Нужна помощь  [new]
Bogdanov Andrey
Member

Откуда: Да уже и сам не знаю...
Сообщений: 2203
pkarklin
Вам надо всего навсего обработать эту исключительную ситуацию.
То есть без обработки исключений все-таки не обойтись. :)
25 авг 08, 14:35    [6105520]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3 4 5 6 7 8 9 10 .. 25   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить