Как сделать чтобы Dataset без SQL считал себя не read-only ?

[delphicoding]

Здравствуйте!
Совершенно идиотская проблема - есть FIBDataset и связанным с ним cxGrid. Прописан SelectSQL. Данные из БД получаются, отображаются, но нельзя ничего изменить ни прямо в таблице cxGrid, ни через Dataset.FN('TEST').Value:=1. Изменение данных начинает работать только после прописки InsertSQL,UpdateSQL - но они в данном Dataset не нужны, тк данные после исправления юзером обрабатываются иначе. Можно как-то сделать, чтобы FIBDataset считал себя не read-only без ненужных insert/update/delete-sql ???

[Stilet]

Я в таких случаях просто вместо DBGrid использовал обычный StringGrid, в который вкачивал данные из бд. Пользователь что-то там менял, но в БД это не попадало (необходимость такая была).
Короче, мой совет - не использовать DBGrid.

тк данные после исправления юзером обрабатываются иначе

Если не секрет как? Они в БД назад не попадают?

[delphicoding]

Это тоже криво, тк требует ручной перекачки данных из Dataset в Grid и пропадают все возможности Dataset.

Данные в БД обратно попадают, просто ради удобства юзера же интерфейс не соответствует напрямую данным в БД, поэтому деяния юзера в интерфейсе приходится разбирать и вручную создавать SQL строки.

[Stilet]

поэтому деяния юзера в интерфейсе приходится разбирать и вручную создавать SQL строки.

Что в этом такого? Юзер то все равно не увидит что делает программа. А если в Программе грамотно построена реакция на деяния пользователя, то и самому программисту не будет сложно ее накодить.

[delphicoding]

Что в этом такого? Юзер то все равно не увидит что делает программа. А если в Программе грамотно построена реакция на деяния пользователя, то и самому программисту не будет сложно ее накодить.

В данном случае используется Dataset.FieldByNameN.OldValue и др. - есть избавиться от Dataset ещё куча нового гемора обретается. Так что нужно решение попроще, чтобы Dataset остался, просто перестал себя считать read-only.

[Stilet]

просто перестал себя считать read-only.

Не знаю как в FB, а в классических ДатаСетах при присосе к SQL запросу связь с базой всегда была только на чтение. Механизмы самого провайдера не позволяли реплицировать в базу данные из вьюшек, которые клиент получает. Одна из причин - выборка может быть с огромнейшими реляциями, тогда бы провайдеру пришлось бы каскадно изменять записи во всех упоминаемых в запросе таблицах - а это одна из самых трудных задач.
Так что думаю твой Датасет будет упираться до последнего.

[delphicoding]

Тупо, что многолетний навороченный FIBDataset в этом вопросе совершенно не разделяет понятий "редактировать данные в Dataset и постить в БД" и просто "редактировать данные в Dataset не отправляя ничего в БД" (для чего совершенно ни к чему insert/update/итп).

[Stilet]

Тупо, что многолетний навороченный FIBDataset в этом вопросе совершенно не разделяет понятий

Не обижайся, но это ты беса гонишь )
FB правильно сделали, иначе бы получилась огромная похуже Оракла СУБД, которая тормозила бы нещадно.

[delphicoding]

FB то тут при чём?! Я говорю Dataset получив данные и сопутствующие параметры (default value, итп) вполне мог бы работать внутри программы и для правки данных без указания строк insert/update. Очевидная недоработка.
Может ты пропустил это, уточню - данные после правки в Dataset ПОСТИТЬ В БД НЕ НУЖНО (по крайней мере этим Dataset).

[Stilet]

Очевидная недоработка.

Они не для этого делались. Они делались как связующие звено между клиентом и провайдером. Смысла нет Датасеты так наворачивать.