Вот совсем уж необъяснимые для меня вещи происходят...

Создаю базу из скрипта и в IBExpert сразу сравниваю её же с исходным скриптом. Типа скрипт на базу только что созданную хочу накатить.
Сравниваю с включённой галкой в опциях компарера Characters sets and collations.

И получаю по этим только что созданным из этого же скрипта свеженьким объектам 500+ расхождений по всем строковым делам.

source (скрипт):



target (только что созданная из этого скрипта база):


Не было бы выделенного комментария, пририсованного при извлечении компарером метаданных из базы, чую, не было бы и расхождений.

Собственно, и IBEScript.dll (2019.1.29.1) генерирует ложные ALTER по этому же, видимо, поводу (и я продолжаю сидеть на IBEScript от 2013 года, ибо он мне по этой причине более симпатичен и генерирует компактные скрипты без ложных срабатываний).
Вот типа такого по приведенному же примеру.


Хотя, шило на мыло ведь явно.


--
"И это пройдет"

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

У меня получилась ооочень неприятная ситуация, когда я клиента остановил в рабочее время не на пять минут как планировал, а на более получаса по той причине, что компареру (IBExpert от 17.03.2019) в результате сравнения скрипта с базой "показалось", что надо дропнуть 30 индексов и потом создать их заново! Я такой подлянки не ожидал, чесслово.
Ладно б всякое PSQL'ное - дропнулось и заново создалось. Но индексы - это долго!!!
Скрин с фрагментом экрана во вложении. Описание индексов в скрипте-источнике и в базе совпадет до символа.

И я теперь скорее либо зарекусь использовать новый компарер в режиме "не глядя" вообще, либо буду использовать IBExpert 2012 года для такого рода сравнений. Как минимум буду рекомендовать местным админам вернуть его обратно (а я молча обновляю IBExpert по мере возможности, если лично попадаю на клиентские серверы).
Но тут дело ещё осложняется и тем, что разработка уже плавно перетекает на FB 4.0. Со старым инструментом бы не хотелось работать, а столь нужная И УДОБНАЯ, И БЫСТРАЯ фича в текущей версии IBExpert поломана напрочь.

Я ж о своём насущном всё... Под три сотни серверов и треть как минимум из них на ADSL в глухих районах.
Текстовые скрипты перегонять туда - самое милое дело, а не бэкапы и тем более базы.
До кардинальной переделки компарера несколько лет назад ну всё ведь было просто замечательно.

Ситуации-то такого вот рода на практике возникают: клиенту надо срочно поправить что-то в бизнес-логике и надо накатить на него текущие метаданные с базы разработки. И по закону подлости это будет кто-нибудь на USB-свистке мобильного оператора, в яме, с пингом 800 мс и скоростью передачи 150кбит/с.
Много больше 10 лет я делал это (и продолжаю делать, пока с этим справляется IBEScript не моложе 2013 года) перегонкой на удаленный сервер скрипта с текущими метаданными, генерацией на удалённом сервере клиента разностного скрипта именно сравнением своих метаданных (как источника) с базой клиента (как с целью) и выполнением этого разностного скрипта для модификации базы клиента.

Нет, я могу, конечно, всю свою автоматику переделать на сравнение с эталонной базой, заморочиться с выкачиванием из своего репозитория архива с БАЗОЙ, а не скрипта с текстом, разворачиванием базы из архива, последующим сравнением эталонной базы, а не эталонного скрипта с клиентской базой...

Но мне непонятна ценность комментирования "автоматически" извлекаемых метаданных, когда они извлекаются компарером именно в ходе операции сравнения скрипта с базой. Я ж не собираюсь глазками читать там эти комментарии о дефолтном чарсете на символьных полях.
Хорошо, пускай они автоматически комментируются, бог с ними - с этими комментариями по чарсетам.
Но тогда можно было б и таким же образом их комментировать и при обычном извлечении метаданных из базы в скрипт (а я именно так готовлю эталонные скрипты для деплоя).
Выходит, что извлечение метаданных в скрипт само по себе и извлечение метаданных из базы в компарере перед сравнением скрипта с базой работает по-разному?!
Или всё же что-то в компарере не так, если он выдаёт ложные срабатывания, приводящие даже к DROP-CREATE одинаково описанных индексов в скрипте и в базе (а база только что была создана из этого скрипта, напоминаю)?

Цель использования компарера (через IBExpert ли, через выполнение ли блока через IBEScript - не важно) лично для меня - получить разностный скрипт. И он нормальный получался до затеянных глобальных переделок компарера. И с годами ситуация сравнения скрипта с базой становится всё хуже и хуже. О чём я и информирую. Я периодически пытаюсь использовать новый компарер для своих привычных целей, но каждый раз получаю эпически провальный результат. И чем дальше, тем более страшный.

Понимаю и то, что проблемы индейцев шерифа не волнуют, что по какому-нибудь хорошо если ADSL 512 килобитному каналу при таком, как я описал, срочном апгрейде придётся перегонять не два мегабайта текста, а 30+ мегабайт (пускай и пустой ) базы. И это реально сожрёт рабочее время и моё, и аборигенов-сисадминов.

Польза от данной фичи (сравнение скрипта с базой) начинает стремиться к нулю, особенно учитывая такие заявления, что "я уже много раз говорил, что для практических целей надо всегда сравнивать базу с базой". Следует ли из этого заявления, что на данный функционал мне нет нужды закладываться вовсе и правиться ничего по этой части не будет?
Имеется ли какая-то теоретическая польза от сравнения скрипта и базы, когда практически результат сравнения в виде разностного скрипта содержит сотни ложных срабатываний по модификации чего-то неизменного, мне не ведомо.
Придётся тогда, видимо, до упора держаться IBEScript (2013) со старой реализацией компарера, который не даёт ложных срабатываний в разностном скрипте и в свободное время переписывать логику дистрибуции изменений с использования сравнения эталонного скрипта на использование для сравнения эталонной базы.

Тем не менее описанный пример скрипта и пустую базу, из него созданную, готов для тестов предоставить.

Сложности - они в трудозатратах на переделку того, что раньше нормально работало, но перестаёт нормально работать по причине изменения алгоритма работы компарера. Ну и во времени на передачу возросшего объёма данных на медленных каналах.

А с индексами-то что не так? Почему компарер возбудился на индексы по текстовым полям?
Только по той причине, что он посчитал что поля требуют изменения, он принял и решение индексы, их использующие, пересоздать? Но по факту-то они незатронуты. Я не трогал дефолтного чарсета на базе, о нём тем более ничего и не знает скрипт. С чего б компареру за меня принимать какие-то решения по части дефолтного чарсета?

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

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

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

Грабли расставлены, я учту, что мне теперь придётся на работы, которые занимали ранее 10-15 минут, в случае работы с актуальной версией IBExpert затрачивать вдвое больше. Но инструмент вроде как должен упрощать жизнь, а вышло, что он усложняет.
Да, сейчас можно начать придираться, что это "мои проблемы". Но компарером для техподдержки удалённых систем раньше было ОЧЕНЬ УДОБНО пользоваться, а теперь стало СОВСЕМ НЕУДОБНО . Как-то очень большая разница в ощущениях при практическом применении.

Вот к чему это всё приведёт в конце концов (и, думается, я не одинок).

Было:
- слить метаданные в скрипт (или вынуть нужные метаданные из CVS-репозитория - мы версируем метаданные для истории изменений, но, впрочем, базы тоже есть)
- передать на клиента этот эталонный скрипт с метаданными
- сгенерировать разностный скрипт сравнением эталонных метаданных с базой клиента
- накатить разностный скрипт на базу клиента
- прочее

Станет:
- слить метаданные с эталонной базы в скрипт (или вынуть эти метаданные из CVS)
или как вариант: выполнить бэкап только метаданных, если эталонная база есть физически
- создать из скрипта пустую эталонную базу (или из бэкапа с только метаданными выкатить её)
- передать на клиента эталонную базу ( плюс архивация-разархивация )
- сгенерировать разностный скрипт сравнением эталонной базы с базой клиента
- накатить разностный скрипт

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

Стало проще? Нет не стало. Стало сложнее.
Стоило ли менять так кардинально алгоритмы, в результате чего привычные действия по работе с компарером серьёзно усложняются? Разработчикам виднее. Наверное, это оправдано.
Понятно, что и поменять привычки и запрограммировать можно всё что угодно.

Лично меня (пока) устраивает компарер 2013 года.
Пока не прижмёт, не буду ничего переписывать под новый.
Ибо таскать базы целиком вместо скрипта - трата времени при дохлом канале. А прикручивать архивацию/разархивацию вообще нет выхлопа, ибо это ради сервисных операций раз в год ... Да, у нас далеко не все все релизы без пропусков ставят. Но раз в пару лет уж точно обновляются, законодательство подстёгивает.
Или ишак сдохнет, или падишах. Время покажет.
Ниже плинтуса так ниже плинтуса. Подождём.