Как можно узнать после открытия TIBDataset были ли в него внесены изменения или нет? Цель - если были изменения, предложить юзеру их сохранить, если не было - ничего не предлагать.

Изменения в текущей записи или вообще в датасете ?

Если последнее, то изменения могут отсылаться на сервер неявно и для "пакетных" правок нужен другой тип датасета, например TClientDataSet

Если первое, то BeforePost с подтверждением сохранения

> Изменения в текущей записи или вообще в датасете ?

Да, вообще в датасете.
> Если последнее, то изменения могут отсылаться на сервер
> неявно и для "пакетных" правок нужен другой тип датасета,
>  например TClientDataSet

Т.е. в стандартном TIBDataset реализация такого механизма будет сложной? или вообще не возможна?

>Т.е. в стандартном TIBDataset реализация такого механизма будет сложной? или вообще не >возможна?

Невозможна, т.к. он не предусматривает сохранение измененных данных локально и при крахе системы или ПК кэшированные изменения буду утеряны и пользователю придется их повторять.

CDS имеет встроенный механизм сохранения данных со всеми изменениями на локальном диске, откуда их можно восстановить при повторном запуске приложения после краха.

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

Мне хочется написать несложное приложение по своей работе, т.к. я вообще продажник и разработка мне не оплачивается. Но хочется, чтобы было удобно работать. И мне нужна след функциональность - есть БД куда в ходе рабочего дня заносятся данные. При этом они не комитятся каждый раз, а могут заносится в БД скопом. Этот скоп накапливается в течении длительного времени, но может и не накопиться. И у пользователя не всегда будет возможность помнить, вносил ли он какието данные, хочется, что бы приложение помнило за него и при необходимости спрашивало, не хочет ли юзер их сохранить. Можно тупо делать коммит каждый раз при закрытии формы, но мне кажется, что куча транзакций будет лишней и является извращением.
Приложение же - стандартные IBExpress + firebird.

ВАХ!!!!

>_drug_   (06.08.09 20:55) [4]

Так и не определена задача и, главное, ПРЕДМЕТ автоматизации.

Но что-то мне подсказывает, что Вам лучше обратиться к специалистам

> [4] _drug_   (06.08.09 20:55)


Используй 2 транзакции, одну для чтения, постоянно активную (длинную), вторую для записи (короткую).
Для чтения и для записи используй разные датасеты. Сохраняй данные (делай коммит) почаще, не стесняйся.

> Loginov Dmitry ©   (06.08.09 22:26) [7]


> Сохраняй данные (делай коммит) почаще, не стесняйся.

Здрасте... Rollback тоже весьма недурственно делать, смею заметить.
У автора каша... Не хочется все объяснять автору.. Долго и нудно все растолковывать... Лень :)

>Loginov Dmitry ©   (06.08.09 22:26) [7]
>Используй 2 транзакции,

И как эти 2 транзакции решат вот эту проблему:

Этот скоп накапливается в течении длительного времени, но может и не накопиться.

Я не новичок в кодинге, поэтому азы мне не нужны, а вопросы я стараюсь задавать попроще чтобы было понятнее, но эффект, смотрю, другой получается - он ничего не знает, а я такой умный, что мне даже не знаю, как объяснить.

Может я не правильно вопросы формулирую?


> Так и не определена задача и, главное, ПРЕДМЕТ автоматизации.

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

> [10] _drug_   (07.08.09 06:54)
> у юзера есть возможность подумать, какие изменения он вносил
> - если полезные, то он сохраняет документ, если никаких
> изменений не вносил, а просто случайно нажал клавишу какую-
> нить, то он отказывается от изменений.

А если были и такие и такие? Причем вперемешку? Вообще странный подход какой то, надуманный.
Поставь какой-нибудь признак в таблице (отдельное поле) Постоянная/Временная запись. Т.е. вносить и коммитить все, ставя по умолчанию статус "Временная". В конце дня выдать все временные и запросить фиксации.

Транзакция автоматически стартуется при обращении к базе.
Соответственно, если какие-то непокоммиченные данные есть,
то она Active = True, т.е. надо писать:

 if DataSet.Transaction.Active then
   DataSet.Transaction.Commit;

Ну или Rollback

>_drug_   (07.08.09 06:54) [10]

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

Немного "практической" теории :)

Если в сетке отображаются объекты, представленные единственной записью БД (например, простые справочники), то никаких кэшей допускать нельзя (за исключением особых случаев) и измененная строка сетки (сиречь запись БД) должна тут же отсылаться серверу.
Если в сетке отображается некий ЦЕЛОСТНЫЙ объект (например накладная или счет-фактура), то кэш может понадобиться хотя бы для того, чтобы вносить в БД не измененные куски, а полностью обновленный (новый) ДОКУМЕНТ. Хотя и в этом случае, ИМХО, много лучше изменения фиксировать в БД, а вот сам документ (или его строки если нет заголовка) помечать как "не введенный полностью". В этом случае потери также будут самые минимальные при любом варианте перерыва в работе (сбой ПК, сети, чай пошла попить а тут звонок и т.д.)

И, наконец, главное: при разработке КОНЦЕПЦИИ интерфейса крайне важно учитывать будет ли приложение работать в многопользовательском режиме. Другими словами: насколько важно чтобы любые изменения, сделанные в документе на одном ПК, были бы оперативно доступны другому ПК. Профи ВСЕГДА руководствуются "многопользовательностью" даже если изначально программа пишется для одного товарисча.

Теперь по существу вопроса с учетом [10]

Если нужно "как в ворде", то в общем случае нужен CDS ибо никакое буферирование не позволит Вам сохранить не переданные серверу данные при аварии, а также весьма сложно контролировать с клиента какие записи НД были отосланы серверу, а какие нет. Кроме того, при буферированном обмене в многопользовательском режиме будут проблемы с конфликтами и их придется решать. Причем алгоритм решения может быть куда хитрее, чем собственно сама программа.

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

Всем кто молится на транзакции:

Что вы советуете коммитить (откатывать) ? Изменения, которые пользователь может вносить на протяжении целого дня ? Типа ввела запись - попила каву, ввела другую - побазарила по телефону с подружкой, ввела третью - сходила в туалет..
А все это время ПИШУЩАЯ транзакция будет висеть и ждать ?

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


Это не извращение. Это как раз правильное поведение - коммитить после каждой подтвержденной пользователем записи.


> Типа ввела запись - попила каву, ввела другую - побазарила
> по телефону с подружкой, ввела третью - сходила в туалет.
> .
> А все это время ПИШУЩАЯ транзакция будет висеть и ждать
> ?


Иногда может быть и так. Это вполне нормально. Время - понятие относительное. Иногда бывает что необходимо группу обращений к базе либо целиком принять, либо отклонить... а пользователь между этим делом может почесать себе че-нить... если приспичит. А уж почесав, нажмет OK. :)

> MsGuns ©   (07.08.09 09:15) [14]

Пару зависаний/пропаданий питания в конце дня, быстро научать делать частые сохранения.

Вот и я на это намякиваю :)

> Sergey13 ©   (07.08.09 08:43) [11]
> > [10] _drug_   (07.08.09 06:54)
> > у юзера есть возможность подумать, какие изменения он
> вносил
> > - если полезные, то он сохраняет документ, если никаких
>
> > изменений не вносил, а просто случайно нажал клавишу какую-
>
> > нить, то он отказывается от изменений.
>
> А если были и такие и такие? Причем вперемешку? Вообще странный
> подход какой то, надуманный.



> >_drug_   (07.08.09 06:54) [10]
>
> В кодинге (дурацкое слово однако), возможно, Вы и не новичек,
>  но в базах, извиняюсь, складывается, совершенно противоположное
> впечатление.
> Хотя бы потому, что подход у Вас к БД как к ворду.


Если вкратце - я стараюсь делать приложении ориентированным на юзера и имеющим возможность скрывать все тонкости реализации и подхода к делу в приложении. В идеале приложение должно быть с одной кнопкой - "Получить конечный результат!". Но при этом приложение должно дать возможность _опытному_ юзеру эти  тонкости использовать. Но в любом случае ориентация на юзера, причем самого неумелого - т.е. приложение подгоняется под юзера. и если юзер умеет работать только с вордом, то и работу с БД я стараюсь организовать максимально похожим образом - т.о. я "учу" приложение работать с юзером.

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

По сабжу благодаря [13] буду изучать CDS. Можно сказать, что этот вопрос закрыл, благодарю за ответы.
А вот по подходу, кто кого "учит" мне интересно знать Ваше мнение.

> [18] _drug_   (07.08.09 10:22)

> имеющим возможность скрывать все тонкости реализации и подхода к делу

Для того что бы скрывать, разработчику надо эти "тонкости" и "особенности" знать, как минимум. Например особенности использования БД. Тонкости взаимодействия клиентской программы и БД. И т.д.

> В идеале приложение должно быть с одной кнопкой - "Получить конечный результат!".
А комп с одной кнопкой ВКЛ/ВЫКЛ. Включил - получил конечный результат. 8-)

> приложение должно дать возможность _опытному_ юзеру эти тонкости использовать
Это наверное значит дать возможность "_опытному_ юзеру" НЕ нажимать единственную кнопку? 8-)