Несколко команд SQL в секции Update SQL.

← →
Patrick (2003-10-06 19:43) [0]

Подскажите, пожалуйста, кто-нибудь, странная вещь, мне необходимо обновить несколько таблиц в результате изменения одной (с триггерами связываться не хочется), у UpdateSQL в секции Modify у одной (главной) таблицы пытаюсь Execute хранимой процедуры, которая изменяет саму таблицу и дочерние таблицы (просто так эта процедура работает) а вот при вызове метода ApplyUpdates, вылезает Updates failed. Пробовал в секции указывать update сразу нескольких таблиц, что-то не проходит по синтаксису. В MS SQL у меня такие вещи проходили, а вот в Interbase почему то нет.

← →
Sergey_Masloff (2003-10-06 22:56) [1]

Потому что при ApplyUpdates проверяется RowsAffected = 1 если не так то получаешь исключение. При вызове хранимой процедуры ес-сно RowsAffected=0. Лови исключение и гаси его - "и будет всем щасте". Только смотри не погаси лишнего ;-)

← →
Patrick (2003-10-07 16:45) [2]

Кстати хочу отметить, что при возникновении ошибки, изменение всё равно производится.Это всё понятно, и лишний раз подтверждает твои слова, но возможно ли сделать таким образом, чтобы в секции указать несколько операторов update для разных таблиц. Как например в MS SQL begin tran ... end tran?

← →
Johnmen (2003-10-07 17:48) [3]

Общий идеологический подход неверен.
Реализация изменений в таблицах на основе изменений в одной таблице строится на триггерах.
Опять же, идеология функционирования TIBDataSet(или аналогов) конструктивно предполагает изменение только одной записи только в одной таблице, из которой и был получен НД.

← →
Sergey_Masloff (2003-10-07 23:04) [4]

Johnmen © (07.10.03 17:48) [3]
>Общий идеологический подход неверен.
Спорный посыл ;-) Есть такое мнение (и не только мое) ;-))
Лично я для себя давно решил - на триггерах по возможности никакой бизнес логики. Только простые проверки, типа дата в диапазоне и каскадные дела. Вся бизнес-логика в хранимых процедурах. Сколько раз я мысленно благодарил всевышнего что сделал именно так - не пересчитать. Потому что так более гибко, понятно, удобно, надежно - и идеологически верно. Хотя бы потому что на одной таблице могут лежать абсолютно разные бизнес-сущности с ОЧЕНЬ разным поведением, и лепить полуторатысячестрочный триггер для учета всего не есть гуд. В то же время при использовании ХП каждый разработчик напишет нужную логику в своей процедуре и может не задумываться над тем что написано в соседней.

← →
Sergey_Masloff (2003-10-07 23:09) [5]

Johnmen © (07.10.03 17:48) [3]
кстати еще маленький штрих. У нас тут был аудит буржуйский, как раз одной из немногих претензий было - многовато у вас логики на триггерах. Типа, немасштабируемо, ненадежно и вообще моветон.
Такие дела...

← →
Johnmen (2003-10-07 23:30) [6]

>Sergey_Masloff

Дела такие...
>Хотя бы потому что на одной таблице могут лежать абсолютно
>разные бизнес-сущности

Не находишь, что это, по меньшей мере, странно и полностью противоречит концепции построения реляционных БД ?

>каждый разработчик напишет нужную логику в своей процедуре не
>задумываться над тем что написано в соседней.

Опять же, весьма странный проект и странные разработчики, которым по-барабану, какая б.-логика уже "навешана" другими ?!

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

Могу согласиться, только если БД спроектирована криво...:)
Это же относится и к >>многовато у вас логики на триггерах.

>Типа, немасштабируемо, ненадежно и вообще моветон.

Смею утверждать, что это некомпетентное заявление.

Короче. Стоит почитать соответствующую литературу, написанную корифеями проектирования БД. Уверяю тебя, после прочтения твое мнение о триггерах изменится...:)

← →
Zacho (2003-10-07 23:41) [7]

Кстати, вот решение: вместо TIBQuery использовать TIBDataSet. И все заработает. :)
:-)

← →
Sergey_Masloff (2003-10-08 00:02) [8]

Johnmen © (07.10.03 23:30) [6]
>Короче. Стоит почитать соответствующую литературу, написанную корифеями проектирования БД.

Это теория же ж... А то практика.
И вообще зря ты с шашкой наскочил сразу. Ты ж не знаешь что у нас за система... Могу сказать что схема разработана в середине 90-х и с тех пор кардинально менять ничего не пришлось - все новые вещи ложатся на старую схему. Мне кажется это вполне доказывает правильность подхода к проектированию.

>Опять же, весьма странный проект и странные разработчики, >которым по-барабану, какая б.-логика уже "навешана" другими ?!
Да просто есть базы несколько выходящие за рамки автоматизации склада на 10 работников ;-) При некоторой размерности по определению часть разработчиков не знает о делах других. Может неудачный пример - например договор продажи пачки сигарет и договор продажи нефтяного танкера - это все равно договор продажи. Но бизнес-логика на них несколько разная, так ведь? И, возможно разработчик реализующий подсистему графика взаиморасчетов с верфью мало знает о процессах доставки табака? Ты предлагаешь делить на разные реляционные сущности эти виды договоров? У кого из классиков это прочитал? ;-) Нет, отношение одно - договор купли продажи. И его разная интерпретация различными подсистемами. В полном соответствии с Дейтом например ;-)

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

← →
Johnmen (2003-10-08 00:36) [9]

>Sergey_Masloff (08.10.03 00:02)

>...зря ты с шашкой наскочил сразу

Ни в коем случае !!! Никогда ни на кого и ни на что не наскакиваю ! Тем более с шашкой...

>Ты ж не знаешь что у нас за система...

Естественно, не знаю. Высказывался из общих теоретических (и практических) соображений. И не только моих.

>а то тут это будет выглядеть как мерянье очередное.

Да не собирался я меряться ! :)

Но все равно остается чувство, что БД спроектирована не вполне корректно...
Мне все интересно, что относится к БД. Но времени на глубокое погружение в чужие системы просто нет ;-)

← →
Sergey_Masloff (2003-10-08 22:28) [10]

Johnmen © (08.10.03 00:36) [9]
>Но времени на глубокое погружение в чужие системы просто нет ;-)
Понятно. Если появится все же писни (напиши в смысле). Система реально уникальная, на территории СНГ аналогов нет точно, в мире не знаю ;-) Счет пользователей - на тысячи, причем компьютер для них-основной рабочий инструмент, не то что раз в день курс валют посмотреть ;-)

Несколко команд SQL в секции Update SQL. Найти похожие ветки