господа, а каким боком execute statement относится к сравнению баз? Не нужен он тут совершенно.

Dimitry Sibiryakovно аффтар решил пойти своим путём и делать это в ХП.
думаю, он случайно увидел буквосочетание ES, и его на нем заклинило. Теоретически через ES и даже ES on external что-то можно сделать, но это а) трудоемко б) тормозно.
Просто сделать два коннекта Snake174 почему-то не догадался.

ну и кроме того, любые "сравниватели таблиц" работают ужасно медленно, потому что алгоритм лучше не придумать.
См. ChangeManager .

Собственно, автор рискует пытаться повторить функционал Change Manager (за исключением сравнения конфигураций).
Для справки - лицензия на раб. место на 1 сервер стоит примерно 960 долларов.
И там все весьма непросто.

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

Наконец, сам алгоритм сравнения двух множеств.

Snake174может быть как-нибудь с помощью SQL можно это сделать быстрее
Ну, через Execute block + execute statement on external можно, но мне кажется, для начала надо сделать вариант без этого. Конечно, при EB+ES с одной стороны не будет буферизации на клиенте, но возможно это и плохо, и также это может работать медленнее "клиентского" варианта.
Придется экспериментировать.

Dimitry Sibiryakov,

ну, да, похоже с буферизацией я прогнал. мысль какая-то проскочила, но не оформилась.

Гаджимурадов Рустам,

а что там я неправильно сказал?

ГР: Как будто про EB+ES ты всё правильно сказал
kdv: а что там я неправильно сказал?
ГР: Да всё, практически.

просто прекрасно. При этом ты сам пронес ахинею, особенно про "типа не сходится - сразу в сад". Потому что он с самого начала писал про diff.

Гаджимурадов Рустам,

согласись, что алгоритмически все должно быть примерно одинаково, что через клиента, что через ES. Но ES гораздо сложнее пишется. Особенно я не вижу смысла в ES при сравнении метаданных.
Так что вполне можно вначале сделать обычного клиента, а потом, при желании - на ES. Мне даже интересно, существует-ли уже у кого то подобное решение.

Гаджимурадов РустамНе совсем. На сервере есть ещё SQL, в т.ч. множественный,
на клиенте же только построчное сравнение.
for select/for execute statement тоже построчный.
while not Q.Eof
do
Q.Next
то же самое. А join из двух баз сделать нельзя. Так что в ES будут те же циклы. А значит алгоритмически решение будет мало отличаться. Ну и, на клиенте запрос для поиска идентичной записи конструировать тоже проще (я про where).

Гаджимурадов РустамТы всерьёз не понимаешь, что это во-первых, мартышкин труд
двойная работа, а во-вторых, тащить (повторяю) все записи обех БД
на клиента не лучшая идея при наличии альтернатив?
Например, я вижу функционал ChangeManager. Он вообще на Java написан. Понятно что ES он использовать не будет.
Допустим, ES альтернатива, но автор-то "не разобрался". Если идеи нет, в ES тоже фигня получится.

Гаджимурадов Рустамkdv> Особенно я не вижу смысла в ES при сравнении метаданных.
Я бы сказал, что никакой разницы нет. Совсем никакой.
есть, потому что в отличие от данных метаданные разбросаны по разным таблицам. Тупо сравнивать rdb$fields не пройдет.

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

Гаджимурадов РустамУ Хвастунова и Лободы? :)
я про сравнение данных и метаданных через ES.