Обновление нескольких таблиц одним SQL-запросом

← →
dmtr © (2003-08-02 13:00) [0]

Подскажите можно ли реализовать сабж?
Ситуация следующая: есть IBDataSet, в который подгружаются данные из трех связных таблиц. Данные отображаются в грид. Я хочу осуществить возможность модификации данных. Если создаю запрос на модификацию полей только одной таблицы, то все нормально, нескольких-соответственно не могу. Может кто подскажет способ осуществить задуманное?

← →
Desdechado © (2003-08-02 16:24) [1]

напиши ХП, в которую будешь передавать как параметры данные строки из своего Dataset. ХП должна их рассовать в нужные таблицы со всеми взаимосвязями.

← →
dmtr © (2003-08-04 10:51) [2]

А можно ли определить какие записи в датасете были изменены или придется в ХП передовать все записи набора данных?

← →
Sergey13 © (2003-08-04 10:58) [3]

2dmtr © (02.08.03 13:00)
>Ситуация следующая: есть IBDataSet, в который подгружаются данные из трех связных таблиц.
ИМХО, редактировать "связанные таблицы" имеет смысл только тогда, когда связь 1:1. Иначе можно нарваться на ситуацию...

← →
Жук © (2003-08-04 11:03) [4]

Я делаю в Modify обновление "основной таблицы", а связанные через Query. Потом просто Refresh. Но это такой геморой, ИМХО. Вариант с ХП поинтереснее будет.

← →
MsGuns © (2003-08-04 11:31) [5]

Подобную траблу решал таким образом:

Компонент для визуализации данных - TIBQuery
Все изменения-вставки через открываемую поверх грида панель с контролами типа TEdit, TComboBox, etc
Собственно изменения в таблицах делаются через отдельную транзакцию компонентой TIBSQL (последовательными запусками на каждую изменяемую таблу сверху вниз при вставке и снизу вверх при удалении)
Затем переоткрытие TIBQuery с позиционированием.

Как правильно сказал Жук © (04.08.03 11:03),- достаточно геморно. Но все работает очень даже кучно и шустро. Просто я не сторонник для каждого зевка лезть на сервер. Доводилось видеть БД с десятком таблиц и более сотни ХП. Что-либо изменить в такой базе (структурно) невозможно. Хотя все это ИМХО

← →
Соловьев © (2003-08-04 11:39) [6]

> не сторонник для каждого зевка лезть на сервер.

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

2Соловьев © (04.08.03 11:39)
Спорно все это.
1. Сервер не обязательно мощнее клиента.
2. Может у него памяти и больше, но и клиентов у него много
3. При изменении логики работы менять придется и на сервере и на клиенте (в программе) - как правило.

>Соловьев © (04.08.03 11:39)

Да ведь никто не спорит. Но все зависит от ситуации. Если проект сделан по принципу "Одна прога - одна БД", то вне всяких сомнений. Если же одна БД обслуживает кучу разных функционально приложений, которые к тому же пишутся разными программерами или даже подразделениями, то тут надо 77 раз омерять прежде чем лезть на сервер.
Хотя это вопрос вообще достаточно тонкий.

ЗЫ. Книжки - вещь чрезвычайно полезная и поучительная. Но ведь они тоже пишутся людьми и не могут к тому же описать ВСЕ ситуации.

А мне привычнее запрос оформить вьюхой а добавление/изменение/удаление записей сделать триггерами.
Очень удобно, думаю, для того вьюхи и существуют.

MsGuns © (04.08.03 11:46)
>ЗЫ. Книжки - вещь чрезвычайно полезная и поучительная. Но ведь
>они тоже пишутся людьми и не могут к тому же описать ВСЕ
>ситуации.
Все - немогут, большинство - могут. :))
Вообще-то легче добавить мощностей в один сервак, чем каждому клиенту все раздать. Вон, есть великолепный пример, когда думает клиент, а сервак бамбук курит: 1С на SQL. :))

Обновление нескольких таблиц одним SQL-запросом Найти похожие ветки