Приветствую всех!
Работаю с FireBird 2.1. 
Есть БД, которая лежит на серваке, и множество клиентов, которые с ней работают по сети! Как при изменении одним пользователем данных в любой из таблиц БД, сообщить об проведенных изменениях другим?
Пользовался обработчиком сообщений post_event, но он немного не подходит, т.к. не удобно обновлять всю таблицу, проще как мне кажется обновить только измененные данные. А в post_event-e, как я понял, нельзя передать параметр, например ID измененной строки, вернее к имени-события его добавить можно, но как его потом получить на клиенте, т.к. предварительно зарегистрировали просто имя-события без дополнительного параметра!
Как на клиенте получить информацию только об измененных данных? Есть ли другие способы кроме post_event-a?

опять  

Добавлено через 47 секунд

точно  , как придумаешь компоненту или алгоритм, сразу можешь запатентовать  

а что там придумывать, все итак ясно как божий день.
Доп. таблица в БД. Поля: имя события, имя таблицы, ИД записи, дата+время
1. Клиент получил событие
2. select из таблицы на обновления, которые появились с предыдущего запроса
3. update нужных таблиц.
4. Обновление статуса последнего запроса
Не очень интересный алгоритм, много косяков будет, нужно сильно дорабатывать.
Лучше дать пользователю информацию, о том что данные изменились, пусть сам по кнопке обновляет.

Deniz благодарю за помощь!
Покапался в инете, и вообщем-то кроме подобной идеи ничего не нашел! К сожалению разработчики FireBird-а не горят желанием вводить параметр в структуру post_event!

Deniz, ну так как же обновить в гриде только изменённые записи, не переоткрывая весь набор данных?

ты меня удивляешь.
как известно Refresh обновляет только текущую запись.
Да сам посмотри, что пишется в RefreshSQL.

Ну теперь представь. Пользователи А, Б, В обновили записи в разных местах таблицы: в начале, в середине и в конце. Теперь нужно, чтобы программа у пользователя Г (да и у всех остальных) пробежалась по гриду и выполнила RefreshSQL только на нужных записях. Т.е. курсор таблицы будет постоянно "блуждать", чтобы обновить ту или иную запись. А если работает 10-15 пользователей...

Добавлено через 2 минуты и 3 секунды
Пользователь ткнёт на запись а мышкой и начнёт перемещать мышь к кнопке Изменить. Пока будет перемещаться мышь... набор данных перепрыгнет на другую запись, чтобы обновить её. И так далее... Т.е. набор данных будет жить "своей жизнью".

Добавлено через 4 минуты и 8 секунд
Чтобы реализовать что-то такое независимое от пользователя, нужно иметь не привязанный к набору данных грид. Чтобы ячейки этого грида можно было обновлять в отдельном потоке.
Какие будут ещё соображения? 
Если я ошибаюсь, то как сделать обновлений в гриде только нужных записей, не мешая пользователю?

см. мои рекомендации.
реализовать что-то типа DisableEvents/EnableEvents на момент обновления не проблема.
"И пусть весь мир подождет" (с)
такое возможно когда работа идет на низком уровне в потомках DataSet'а или грид должен быть StringGrid'ом (или что-то в этом духе). Смысл тратить время на реализацию данного механизма я не вижу, следовательно, если кто-то сильно хочет "удивить" пользователя и автоматически обновлять данные, удачи.
Сам объясняю пользователям так: "Представь, что это распечатанный список. Ты можешь его руками править и т.д. Но чтобы получить новые данные, тебе нужно его еще раз распечатать, т.е. обновить. Когда нужны новые данные жми кнопку." Вот и все.

так и я о том же 

С практической точки зрения, лучше ничего не обновлять и просто сообщать пользователю что данные изменились. Если он работает и ему это надо, то он сам обновит. Зачем на сервер нагрузку лишнюю создавать? =)

А как вариант - записывать ID всех изменённых записей в отдельную таблицу. А клиент, чтобы при получении события проверял эту таблицу и смотрел какие там данные появили с момента последней проверки. А где-нить в полночь таблицу эту чистить, например. 

А смысл такой таблицы,  если будет кнопка Обновить. 

т.е. мой вариант в 3 посте тебе не понравился?   

когда пользователь нажал на кнопку обновить, можно обновить только измененные записи.

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

ты описал тоже самое
сравнидумаю на этом пора закончить, а то автор уже пометил вопрос как решенный, а мы все не уймемся