Еще раз всем привет. Из БД получена составная таблица (SELECT

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

Можно делать. Вот только я мог делать так, чтоб изменился данные только у одной таблицы.

с одной таблицей вопросов не возникает) А вот, с собранной из разных как быть?)

А поля ReadOnly сделать или колонки?

А поле и колонка не одно и тоже, разве? Вообще, да, потом надо будет закрыть редактирование остальных полей, но это, думаю, в свойствах грида поискать потом

Для простоты если, то у поля может не быть колонки. Поле из запроса, колонка из грида)

Спасибо за объяснение) Вопрос остается открытым))

Грид хоть какого класса?

TDBGrid

Не, почти не работаем с непосредственным вводом. Грид-кнопочки-форма...

Не, я именно одну из собранных изменял. Просто прицеплял UpdateQuery туда запросы писал :)

А какие события каких компонентов ловили?

Так-то можно и мемтаблю прицепить и на post свой SQL посылать

MemTableEh?

Да любую, какая доступна

понятия не имею, что это такое. Что значит которая доступа? Их несколько бывает?)

Не ловил. Просто у TFDQuery есть свойство UpdateObject. Вот к нему прицеплял TFDUpdateSQL.

Это разные компоненты, произведенные от TDataSet. Да, их несколько

Либо через настроенное представление с некоторыми ограничениями, либо как выше писали разные скрипты обновления писать

Это из отдельного пакета ehlib. Там есть комбинация datadriver <> memtableeh <> dbgrideh. Там можно сразу прописать скрипты select/update/insert/delete и оно напрямую с грида работать будет

ммм. Звучит вкусно) Спасибо за объяснение

view и instead триггеры. Либо cache и процедуры

а зачем?

Зачем пользователю редактировать данные или что зачем?

зачем редактировать данные join-запроса

пользователю выводится информация в удобном для него виде и нужно вносить изменения в эти данные.

не делайте винегрет, потом заплутаете.. там, где select..join - это статистика, и она должна быть RO

А кстати почему? ) Я тоже при ReadOly сказала для простоты, но ведь можно и по кнопочке выбрать из выпадающего списка

я за чёткую логику, а не за то, что "удобно пользователю"

А что в этом нечеткого? Один кодик заменить на другой в записи, выбрав из справочника

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

Аа, вы про это. Откуда скажем мемтабля вообще понимает куда сохранять кроме себя, Ну или TQuery

Гуй нужно проектировать так, чтобы понятия "четкая логика" и "удобство пользователя" были объединены в одно логичное целое :)

согласен, это должно быть в грамотном ТЗ.. но это всё в идеале, на практике редко встречается )

Увидишь грамотное ТЗ - поделись, мы его распечатаем и поместим в рамку гденибудь на ВДНХ в зале "Народные достижения".

Не совет для конкретно твоей проблемы, а просто, чтобы была общая картина: на стороне RDBMS можно задействовать процедуры и/или изменяемые view. Все сильно зависит как от проекта, так и от базы.