Начинаем тестировать ФБ4 и...

В firebird.conf для ФБ4 прописываем:




Берем архив базы с сервера ФБ 3 и восстанавливаем.

Подключаемся -- идут ошибки в нашей программе на длину поля.
Выполняем запрос на RDB$FIELDS для домена RDB$FIELD_NAME
получаем такие параметры:




Т.е. ничего к совместимости с 3.0 не привелось.

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

а для чего тогда вообще этот режим?

в данном случае мне представляется логичным такое поведение сервера:

если установлены указанные выше параметры и восстанавливается бд из архива, то:

1) метаданные RDB$ таблиц создаются в соответствии с указанными параметрами.
т.е. длина идентификатора 31 символ.

2) при восстановлении, если в архиве нет идентификаторов длиннее (без учета
концевых пробелов), то процесс восстановления проходит без ошибок и
предупреждений.

3) если есть -- выдается сообщение об ошибке и процесс прекращается.

4) тоже самое и с новыми типами данных, если установлен режим совместимости
3.0 или 2.5. т.е. встретились данные новых типов -- ошибка. нет -- процесс проходит
без ошибок.


Указанное выше поведение позволит не только спокойно восстановить БД из 3.0
в 4.0 и продолжить работу с существующим софтом, но, и понизить режим
совместимости для БД, ранее созданной под новые метаданные 4.0.

ладно, просто оставлю это здесь:

авторДжон Росс, написавший первоначальную версию SimCity для Windows 3.x, рассказывал мне, что у него была случайная ошибка в SimCity, когда он читал память, которую только что освободил. Под Windows 3.x все работало прекрасно, потому что память никуда не уходила. Но вот что поразительно. При тестировании бета-версий Windows 95 обнаруживалось, что SimCity не работает. В Microsoft нашли ошику и добавили в Windows 95 специальный код, который проверял, не выполняется ли SimCity. При обнаружении SimCity выделение памяти переводилось в особый режим, в котором память не освобождалась сразу. Эта помешанность на обратной совместимости способствовала переходу пользователей на Windows 95.


никакой кривизны клиентских библиотек нет. для ORM надо больше информации, чем есть в RDB$ и она хранится в отдельных таблицах. естественно, что там был домен на 31 символ. мы конечно придумаем что делать с этим, но это задача не наивысшего приоритета, так что придется перенести тестирование ФБ4 куда нибудь на сентябрь.

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

в качестве примера, как можно отвечать на вопросы и вести дискуссию:

https://stackoverflow.com/questions/66763171/does-firebird-support-infinity-as-float-value

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

Не проблема, сколько ты готов заплатить чтобы режим совместимости Firebird работал так,
как ты хочешь?


Думаю, не только нам будет интересен режим совместимости "из коробки".
Если организовать сбор, я бы скинулся.

на классике. и фб 4 тоже в режиме классик планируем ставить. мы так и не смогли даже приблизиться
к воссозданию ситуации с повреждением БД под супером. но, она происходила стабильно каждые 2-3 месяца.
База 260 Гб, количество пользователей 300, очень большой кэш -- на размер всей базы.

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

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

я думаю, что в документации стоит отразить, что параметры в RDB$ таблицах не зависят от параметров в firebird.conf файле.
и точно указать место, где происходит проверка/усечение данных, чтобы разработчики систем могли четко представлять
где у них вылезет несоответствие новых и старых типов.

сейчас релиз ноты выглядят так:

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Parameters to Restrict Length of Object Identifiers

Object identifiers in an ODS 13 database can be up to 63 characters in length, and the engine stores
them in UTF-8, not UNICODE_FSS as previously. Two new global or per-database parameters are
available if you need to restrict either the byte-length or the character-length of object names in
ODS 13 databases for some reason.

Longer object names are optional, of course. Reasons you might need to restrict their length could
include:

• Constraints imposed by the client language interface of existing applications, such as gpre or
Delphi
• In-house coding standards
• Interoperability for cross-database applications such as a third-party replication system or an
in-house system that uses multiple versions of Firebird

This is not an exhaustive list. It is the responsibility of the developer to test usage of longer object
names and establish whether length restriction is necessary.

Whether setting one or both parameters has exactly the same effect will depend on the characters
you use. Any non-ASCII character requires 2 bytes or more in UTF-8, so one cannot assume that
byte-length and character-length have a direct relationship in all situations.
The two settings are verified independently and if either constrains the length limit imposed by the
other, use of the longer identifier will be disallowed.

If you set either parameter globally, i.e. in firebird.conf, it will affect all databases,
including the security database. That has the potential to cause problems!

MaxIdentifierByteLength

Sets a limit for the number of bytes allowed in an object identifier. It is an integer, defaulting to 252
bytes, i.e., 63 characters * 4, 4 being the maximum number of bytes for each character.

To set it to the limit in previous Firebird versions, use 31.

MaxIdentifierCharLength

Sets a limit for the number of characters allowed in an object identifier. It is an integer, defaulting
to 63, the new limit implemented in Firebird 4.

автор# Set to 31 to limit as Firebird 3 and previous versions.

По разному можно эту строку из .conf файла понимать.
Например, что обеспечивается совместимость по длинам
идентификаторов с версией Firebird 3.