Имеется база firebird и триггер вида:

CREATE OR ALTER TRIGGER MyTest FOR CONTACTS 
  ACTIVE 
  AFTER INSERT OR UPDATE OR DELETE
  AS BEGIN
  POST_EVENT ('CONTACTS_NOTIFY_' || NEW.ID);
END

Проблема в том, что не понятно как объяснить qt, что нотификация переменная строка, а не постоянная? Или qt не может с такими событиями работать?
То есть, если бы я написал просто "CONTACTS_NOTIFY" - то все работает отлично, но мне нужно так же получать и новый id вместе с сигналом.

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

Такой вариант не получится и не только в Qt.

БД шлёт уведомление, ПО по этому уведомлению смотрит, что изменилось.

Можно смотреть самый большой ID-шник, например.

Хм. А как тогда можно узнавать какие именно строки изменились? Что бы каждый раз всю таблицу не обновлять?

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

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

-- 2 --
Если используешь сигнализацию на уровне БД/Приложения (т.е. из хранимой процедуры), то может понадобится вспомогательная таблица.

У меня (в процессе разработки систем сбора данных) появилась привычка, делать таблицу, которую я обзываю - "Летопись".
Т.е. ни в каких таблицах я не держу полей типа - штамп времени (со встроенным типом данных - timestamp).
А делаю таблицу:
id | timestamp | where | what
В эту таблицу, все тригерры и ХП обязаны заносить текущие дату-время, т.е. отмечать штамп времени всех событий.
а в другие таблицы помещаются Id-шники из этой таблицы.

поле "where" у меня содержит имя объекта БД (имя таблицы или ХП, но не тригера, т.к. он привязан к таблице)
поле "what" даёт некое описание события (тут нужно придумать правило, что туда писать).

Можно использовать эту вспомогательную таблицу для определения того, что изменилось в БД.

Спасибо. Понятно.
Я подумав тоже решил делать доп таблицу, а оказывается распространенный подход.

Только один момент. Синхронизация времени. То есть или на всех машинах-клиентах + сервер нужно иметь одно и тоже время, или брать время у сервера.

да у него. Причём это довольно просто:

SELECT current_timestamp FROM foo

Где foo произвольная, существующая таблица, например: rdb$database

(Взято из доки)

Ясно. Спасибо.