Как можно узнать после открытия 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-)

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

Без сомнения.
А если не знаешь тонкости, ртфм для начала, ну, если вопросы остались, можно спросить у знающих людей.

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

Я же утрирую )))

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

У опытного должна быть возможность нажать дополнительные кнопки. Такой идеальный симбиоз никсов и винды - продуманно как никсы и удобно как винда. Если ты домохозяйка - ты нажимаешь кнопку пуск, если сисадмин - командная строка тебе в помощь.

>_drug_   (07.08.09 10:22) [18]
>Если вкратце - я стараюсь делать приложении ориентированным на юзера и имеющим >возможность скрывать все тонкости реализации и подхода к делу в приложении.

Любое приложение априори на юзера. На то оно и ПОЛЬЗОВАТЕЛЬСКОЕ приложение.

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

>В идеале приложение должно быть с одной кнопкой - "Получить конечный результат!".

Авто с одной педалью ? Авто и приехал куда надо ?

>Но при этом приложение должно дать возможность _опытному_ юзеру эти  тонкости >использовать.

Писать приложение под опытного пользователя - в корне ошибочное решение. Хотя бы потому что характеристика "опытный" Вами и пользователем понимается по-разному, иногда абсолютно. Вы под опытным имеете в виду огурца, лихо давящим клаву 8-ю пальцами, а он - человека, специалиста в ЕГО РАБОТЕ, т.е. опять же ПРЕДМЕТЕ автоматизации. Можно написать навороченную бухгалтерскую прогу с тучей фич, работать с которой не будет ни один бухгалтер ибо она не делает того, что ЕМУ НУЖНО.

>Но в любом случае ориентация на юзера, причем самого неумелого - т.е. приложение подгоняется >под юзера.

Никого и ничего не надо "подгонять". Опять же - это как бинокль для косоглазых. Приложение должно "подгоняться" не под пользователя, а под ПРЕДМЕТНУЮ область - тогда 99% всех пользователей с удовольствием будут с ней работать.

>и если юзер умеет работать только с вордом, то и работу с БД я стараюсь организовать >максимально похожим образом - т.о. я "учу" приложение работать с юзером.

Еще одна типичная ошибка - "сделать как в ворде (екселе)". А если так уж надо, то и используйте сам ворд, а не изобретайте интерфейс "как в ворде", тем более, что все равно лучше не сделаете, а сделаете гораздо хуже - к гадалке не ходить.
Благо делфа позволяет такой "симбиоз" с весьма обширными возможностями "тудом-сюдом"

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

Это не демонстрация, а попытка объяснить Вам прописные истины в области, для Вас совершенно новой. И "демонстрируют" этот подход люди, десятки лет работающие с этими самыми "юзерами", причем самыми разными и в самых разных областях бизнеса, экономики и производства.

>По сабжу благодаря [13] буду изучать CDS.

CDS - лишь один из вариантов и не факт, что оптимальный именно для Вашего случая.  
Советовать Вам что-либо более конкретное мешает полное отсутствие информации о решаемой Вами проблеме.

>А вот по подходу, кто кого "учит" мне интересно знать Ваше мнение.

Мнение одно: разработчик учится у пользователей в ПРЕДМЕТНОЙ области, аккумулируя знания, полученные у РАЗНЫХ людей. А затем разрабатывает программы, работе с которыми уже он учит пользователей. И процесс этот бесконечный.

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

> [20] _drug_   (07.08.09 13:35)
> У опытного должна быть возможность нажать дополнительные
> кнопки. Такой идеальный симбиоз никсов и винды - продуманно
> как никсы и удобно как винда. Если ты домохозяйка - ты нажимаешь
> кнопку пуск, если сисадмин - командная строка тебе в помощь.

Много говоришь, даже с терминами. Только не по делу.
Например так и не понятно - сколько людей будут одновременно работать с базой. Принципиально - один или больше?
В твоей "задумке" про "заносится в БД скопом. Этот скоп накапливается в течении длительного времени" есть маленький нюанс. Ты можешь гарантировать, что твоя БД находится в том же состоянии, что и в начале сессии? А что она вообще доступна? А что твой "скоп" не вылетел вместе с пробками на щитке?