Differences between Firebird and InterBase

InterBase was created in 1985: it was the first commercial multi-versioning database. In the end of 1999, Borland decided to close InterBase development and published its source codes under InterBase Public License. This code was copied (it is permitted by the license), and Firebird was born – from the version 1.0 Firebird is a production-ready database, based on previous decades of InterBase development.

Как не запутаться в зависимостях объектов ПИ

Уже миллион раз успел пожалеть, что сделал в Гедымине режим добавления объектов в ПИ "с зависимыми". Это мощная функция, которая требует от применяющего досконального знания теории реляционных баз данных, структуры конкретной БД, внутреннего устройства своего прикладного решения.

Добросовестная разработка с использованием данной галки требует следования определенной последовательности операций:

1. Добавить объект в ПИ с зависимыми.
2. Открыть список ПИ. Найти нужное и по-порядку, по списку входящих в него объектов, проверить что именно добавилось. Убрать лишнее.
3. Открыть список зависимостей для выбранного ПИ и проверить какие зависимости добавились. При необходимости изменить.
4. Сохранить ПИ в репозиторий.
5. Взять чистый эталон и загрузить на него пакет (каждый функционально завершенный и обособленный модуль должен быть оформлен в виде пакета).
6. Протестировать работоспособность загруженного пакета.

Очень важно! Добавление с зависимостями можно делать, если разработка ведется на отдельной, специально выделенной, чистой актуальной базе данных.

Почему?

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

1. В такой базе может присутствовать целый букет устаревших, временных, давно забытых ПИ. При добавлении "с зависимостями" они подхватятся и затянутся в список зависимых ПИ.
2. В таблицах на таких БД могут присутствовать устаревшие, уже не используемые поля. Мало того, что они затянутся в ПИ, так еще затянутся и объекты на которые они ссылаются.
3. Устаревшие скрипт-функции могут привести к тому, что код, работающий на разработочной базе, не будет работать на чистой базе, собранной из актуальных ПИ.

Прозаическая реальность оказалась далека от ожиданий. Добавление с зависимостями применяется чтобы на скорую руку получить результат, а какого он будет качества мало кого волнует. Потом, когда выясняется что ПИ не устанавливается, требуется затратить в 10 раз больше усилий, чтобы распутать зависимости между объектами и файлами ПИ.

Если не уверен в себе и на все 100% не понимаешь что происходит "под капотом" системы, то каждый объект надо добавлять в ПИ вручную, по-отдельности, в порядке реляционной зависимости. Что особенно ценно, при добавлении вручную маловероятны ситуации "запутывания" связей между объектами или файлами ПИ.

После автоматического добавления с завимостями следует тщательно изучить и скорректировать список зависимых ПИ. Общее правило тут такое: чем меньше зависимостей, тем лучше.

Пример: пусть мы создаем небольшое прикладное решение, расширяющее стандартный пакет Зарплата и Кадры. Назовем его Наряды.

1. Поскольку решение не велико, то объекты разобъем по следующим ПИ:
   • GS.Зарплата.Наряды.Метаданные -- домены, таблицы, триггеры и т.п.
   • GS.Зарплата.Наряды.Хранилище -- экранные формы.
   • GS.Зарплата.Наряды.Макросы -- перекрытые методы, локальные макросы форм.
   • GS.Зарплата.Наряды.Отчеты -- печатные формы.
2. Зависимости настроим следующим образом:
   • GS.Зарплата.Наряды.Метаданные зависит от пакета GS.Зарплата.
   • GS.Зарплата.Наряды.Хранилище зависит от GS.Зарплата.Наряды.Метаданные.
   • GS.Зарплата.Наряды.Макросы зависит от GS.Зарплата.Наряды.Хранилище.
   • GS.Зарплата.Наряды.Отчеты зависит от GS.Зарплата.Наряды.Макросы.
3. Создадим пакет GS.Зарплата.Наряды и сделаем его зависимым от GS.Зарплата.Наряды.Отчеты. Обратите внимание, что нет необходимости в пакете ставить зависимость от всех ПИ нашего решения, так как между ними итак уже присутствуют зависимости.
4. Сохраним ПИ в файлы и расположим их в подкаталоге Наряды в папке Зарплата и кадры.
5. Запишем в репозиторий.
6. Подключимся к чистой эталонной базе данных ипоставим на загрузку пакет GS.Зарплата.Наряды. Проверим, чтобы загрузка не кидала ошибок. Проверим работоспособность после загрузки.