Я б так сделал:

Сервер БД
1. Создаётся в базе табличка "Свежесть справочников" "Справочник"-"Время последнего обновления"
2. В базе создаётся табличка "Грохнутые элементы" "Справочник"-"ID_удалённого_элемента"-"Время удаления"

В каждом справочнике добавляется столбец x_datetime, индексируется и навешиваются однитипные триггеры на справочники:
- на вставку/обновление обновляет x_datetime
- на удаление: добавляет строку в "Грохнутые элементы"
в обоих триггерах обновляется "Свежесть справочников"
---

Клиент
1. Открываем справочник "A" и перегоняем его в InMemory-Dataset, локальный индекс которого построен по первичному ключу.
2. Запрашиваем из таблицы "Свежесть справочников" дату обновления справочника "А" (или всех сразу с сохранением в памяти).

Работа с этим мясом на стороне клиента
При каждом обращении к справочнику "А" (открытие формы, нажатие на кнопку и пр.):
1. Делаем запрос к табличке "Свежесть справочников" и получаем дату последнего обновления "А" на сервере. При достаточной частоте этих запросов табличка помещается в горячий кэш сервера и живёт фактически в памяти, время отклика здесь не критично, 99% операций - чтение.
2. Сравниваем полученную с сервера дату с той датой, которую мы сохранили по этому справочнику, когда его открывали.
3. Если даты совпадают, то справочники не обновлялись, можно использовать существующие данные в InMemoryDatasete.
4. Если даты не совпадают, то справочники обновлялись, делаем следующее:
- запрос select * from A where x_datetime > "Локальная дата обновления". Мы получим ТОЛЬКО новые и обновлённые записи. Их можно обработать локально по-разному, если закэшировать максимальный числовой идентификатор справочника, то можно чётко разделить, что добавлялось, а что обновлялось, новые записи добавляем в InMemoryDataset, обновлённые ищем локально по первичному ключу (локальному индексу) и обновляем.
- запрос select * from "Грохнутые элементы" where "Справочник" = "A" and "Время удаления" > "Локальная дата обновления". В результате получим удалённые элементы ТОЛЬКО с момента последнего обновления справочников. Ищем их по индексу в InMemoryDS и удаляем.
Последний штришок: сохраняем в локальную дату обновления справочника А дату, полученную на первом шаге.

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

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

Подобная техника используется компонентами SDAC при обновлении результатов запроса (метод QuickRefresh) при соблюдении определённых правил на сервере...

_no_test_кто мешает показывать правую сторону экрана только:
Так и показывается.

- первый раз при открытии формы вкладка 0
Ну да, только на вкладке 0 тоже есть списки.
Даже, например, список "Класс бонус-малус" на вкладке 1. Если какой-то класс был удалён администратором, нужно перезаполнить список.

Зачем тебе кэш?
Я имею ввиду, кэш, не как отдельную сущность, а как "нормальное состояние".
Т.е., например, "Класс бонус-малус" кэшируется в списке. Список просто не обновляется.
Зачем его обновлять?
Ведь, практически классы уже несколько лет не меняются (разве что, коэффициенты).
Но, теоретически администратор может изменить этот справочник, используя клиент.

Плюс, на вкладке 1, должен обновиться водитель в списке водителей, данные страхователя, данные владельца, при каком-либо их изменении.

Сейчас подумал.

Решил сделать нечто вроде такого:
1.) Сервер.
Триггеры (AFTER) пишут в таблицу обновлений данные.
Имя таблицы.
Ключ записи. Если составной, то разделяется, к примеру, символом ';'.
Время обновления.
Действие или его код: update, insert, delete.

Планировщик (или триггеры, пока не решил) удаляет все записи таблицы после опр. времени (больше времени обновления клиента).

2.) Клиент.
Имеется объект "Диспетчер обновлений".
Данный объект реализует:
а.) Автоматическую загрузку таблицы обновлений.
б.) Хранение времени последнего обновления таблиц.
в.) Разбор ключа.
г.) Сравнение времени обновления коллекции сущностей или списка записей с таблицей.
д.) Генерацию событий, оповещающих об обновлении.

Интерфейс подписан на события диспетчера и реализует обновления "отображения".
Коллекции объектов хранят время последнего обновления.

Не знаю, пока что, как будут управляться коллекции. Либо "через интерфейс", либо "напрямую" из диспетчера.

Что скажете, стоит подобное делать?

Хм... прошу прощения, я почти то же самое описал, не углядев данного поста.
В вашей сложившейся ситуации (переход невозможен и пр.) другого варианта не вижу... дерзайте))

Тут ещё идея в голову пришла, кэш справочником и датами обновлений можно на винт сохранять. Тогда, если справочник не обновлялся, он вообще с сервера запрашиваться целиком не будет, если есть на винте...

LSVЧто-то идея сохранения справочников локально пахнет началом 90-хх, DOS-ом и поделками "файл-сервер" некоторых фирмочек. Экономия на спичках, ИМХО.
В эру промышленных СКЛ-СУБД это неактуально. Экономия составит 0,5% трафика.

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

Согласен... Но у автора есть определённые условия, которые не позволяют ему "перекроить" справочную систему.

LSVЧто-то идея сохранения справочников локально пахнет началом 90-хх, DOS-ом и поделками "файл-сервер" некоторых фирмочек. Экономия на спичках, ИМХО.
В эру промышленных СКЛ-СУБД это неактуально. Экономия составит 0,5% трафика.

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

Можно смотреть на технологию локального сохранения с двух точек зрения:
- это основная технология, которая обеспечивает программу справочной подсистемой
- это опциональный кэш, который можно в любой момент отключить
Я рассматриваю эту штуку, как дополнительный модуль кэширования. Ведь никто не говорит, что кэш в браузере - это пережитки 90-х в эру высокоскоростного интернета, он экономит трафик и даёт прирост производительности. Тут, собственно, то же самое. Система должна оставаться работоспособной и без него. Файлы кэша могут быть даже в каком-либо внутреннем формате (я выбрал бы дамп памяти MemDataseta), тут цель - производительность. Но, насколько я помню, автору немного не это нужно было.

Petro123-=*ShamaN*=-,
всё стои деньги.
Кэш даже на HDD без обоснования в виде "счётчиков попадания" никому не нужен.
Только делает систему глюкавее и дороже.

без обоснования - т.е. всё от ситуации зависит