Представляю вниманию Delphi-программистов библиотеку функций IBXFBUtils.
Библиотека позволяет упростить разработку приложений БД Firebird, а также самих баз данных.
Наиболее значимые возможности библиотеки:
- создание базы данных с нуля (со всеми таблицами, полями, хранимыми процедурами и т.п.);
- добавление в БД новых объектов в любое время, исправление некоторых объектов;
- пул подключений;
- хранение разнородной конфигурационной информации в БД (по типу INI-файлов, но возможностей намного больше);
- простые функции для резервирования / восстановления БД;
- функции для модификации данных;
- и многое другое.

Библиотека основана на компонентах IBX, поэтому, если Вы используете IBX, то можете подключить IBXFBUtils к своему проекту и получите новые возможности.

Более подробную информацию читайте в СТАТЬЕ .
Библиотеку можно скачать c гитхаба: https://github.com/loginov-dmitry/ibxfbutils
(старая ссылка - уже неактуально архив ).

Конструктивные замечания, пожелания и критика приветствуются.

deboseА какие условия использования библиотеки? Не нашёл упоминаний ни в статье ни в исходниках.

Безо всякий условий, гарантий и прочего. Библиотека бесплатная.

Забыл отметить: тестирование производилось на D7, D2007, XE2 x86, FB2.0, FB2.1, FB2.5.

A-n-d-r-e-yТак появилась статья Почему мне нравится Firebird .
ссылка на:
file:///C:/Users/Dima/AppData/Local/Temp/www.loginovprojects.ru/index.php?page=whyfirebird

Спасибо, исправлено!

xen2При исправлении описания объектов "Поле", "Первичный ключ", "Внешний ключ", "Индекс", "Домен", "Проверка" коррекция БД не производится. очень жаль!

Возможно в перспективе подобный функционал появится.

xen2тогда условную сверхзадачу "ibexpert - на свалку" можно было бы считать решенной


Никогда не задумывался

Пожалуйста, давайте не будем обсуждать эту статью здесь (это бесконечный процесс, к тому же ветка для обсуждения есть на соседнем форуме).

Кто-нибудь пробовал компилировать проект, есть ли замечания?
Особенно интересует D2009, D2010, XE (в какой-то из них произошли довольно значительные изменения в IBX).

Не знаю, кто у кого "родитель", но
так было, есть и будет! )

xen2при запуске теста "Коррекция структуры БД" выдает:
D7 Lite Full / FB2.1 / Win XP SP3

Что это была за версия FB2.1 (может betta)?
Я до сих пор использую самый первый релиз FB2.1, ни разу с ним проблем не имел )

xen2похоже, у ФБ размер страницы по умолчанию изменился


В библиотеке константой задан размер страницы 8 КБ.

DelphiCoder_1980авторIBX тут ни при чем, что ли? Почему тогда нет свойства LibraryName?

Я бы не стал так категорично задавать вопрос, но считаю, что добавить это свойство было бы очень полезно.

Сомневаюсь, что авторы библиотеки IBX пойдут на это. GDS32.dll жестко зашита в недрах IBX, врядли с этим что-то сделаешь. В качестве выхода из ситуации я предлагаю явно указывать месторасположение библиотеки GDS32.dll в модуле fbUtilsLoading.pas

kdvа еще имена библиотек зависят от разрядности. у ИБ это gds32.dll и ibclient64.dll.

Поддержка 32-разрядной IBX досталась Firebird'у по наследству, но сомневаюсь, что кто-нибудь возьмется за реализацию ibclient64.dll под Firebird... :(

Библиотека ibxFBUtils обновлена.
Ссылка на проект на гитхабе - в первом сообщении топика.


Фактически закоммичен рабочий вариант библиотеки (он используется на работе) со всеми последними изменениями. На работе используем Delphi2007, основное тестирование осуществляется именно с этой версией Delphi. Основанные на ibxfbutils решения фактически экслуатируются месяцами, в некоторых случаях - годами (службы на серверах), без перезапуска ПО.

Что нового (попытаюсь за 20 минут вспомнить основные изменения за последние 5 лет):

1. Исправлена работа с пулом подключений и с fb.Ini. За несколько лет эксплуатации были выявлены проблемы, они устранены.

2. Выполнен ряд корректировок для ускорения взаимодействия между клиентом и сервером по медленным каналам связи. Выяснилось, что если канал связи менее 1 МБит/с (на практике - через Интернет, либо через VPN, либо через медленный WiFi), то запросы существенно тормозят. Это происходит из-за необходимости препарации запросов (Prepare). Причем сам запрос выполняется чаще всего гораздо быстрее, чем его препарация (видимо, этап препарации состоит из нескольких обращений к СУБД). Для решения данной проблемы введёны дополнительные методы (например, fb.GetDataSet, fb.GetAndOpenDataSet), которые по тексту SQL-запроса отыскивают и возвращают существующий датасет. При завершении работы с таким датасетом достаточно вызвать метод TIBDataSet.Close (вместо Free). В качестве владельца таким датасетам назначается объёкт TIBTransaction.
Следует учитывать, что если в датасете изменить текст SQL-запроса, либо завершить транзакцию, то информация о препарированных запросах будет потеряна (при следующем запросе операция Prepare будет выполнена заново).
2.1 Методы fb.UpdateRecord, fb.InsertRecord, fb.DeleteRecord внутри используют функцию FBGetDataSet, что позволяет существенно ускорить вставку/обновление/удаление множества записей в одной транзакции на медленном канале связи.
2.2 В Метод fb.GenID добавлена возможность указания объекта TIBTransaction (раньше передавался только объект TIBDatabase, а транзакция на запись создавалась каждый раз автоматически).
2.3 В пуле подключений транзакции на чтение теперь остаются всегда активными (это необходимо учитывать, если SQL-запросы включают функцию LIST, т.к. в памяти остаются объекты, до тех пор, пока транзакция не будет завершена).
3. Исключение, возникающее в функции FBDisconnectDB при вызове TIBDatabase.Connected := False теперь перехватывается и никак не обрабатывается. Выяснилось, что нет никакого смысла пытаться обработать подобные ситуации, а если исключение не заглушить, то программа не сможет корректно обработать ошибку.
4. Добавлен метод GetCurrentDateTime.
5. Добавлены методы GetTableFieldValue, GetTableFieldValues, избавляющие от необходимости объявлять переменную TIBDataSet в том случае, если из таблицы запрашивается лишь одна запись.

Кроик СемёнDmSer,

вы молодец, что делитесь наработками.

Данный проект изначально разрабатывался во внерабочее время, т.е. дома. Проектами, которые разработаны в рабочее время, делиться совесть не позволяет :)

Кстати, вот ещё решил обновить проект LDSLogger. Ссылка для SVN-клиента:
https://svn.code.sf.net/p/loginovprojects/code-0/trunk/ldslogger

По сравнению с тем, что было раньше - решены проблемы с производительностью в режиме LazyWrite:
Раньше каждая строка записывалась в лог отдельно, из-за этого бывали случаи, когда данные в лог писались медленнее, чем программа вызывала метод LogStr(), что могло приводить к ошибке Out of memory. Cейчас сначала формируется буфер из всех строк, которые нужно записать, а затем одним разом буфер пишется в файл. Опять же, основное тестирование выполняется в D2007.

Решение поддерживает одновременно множество лог-файлов (конкретно в моём приложении может выполняться обмен с сотнями контроллеров, для каждого контроллера отводится свой лог-файл). При этом никаких тормозов в режиме LazyWrite не возникает (в виде чрезмерной нагрузки на диск и следствие - синий экран), поскольку вся запись выполняется через один единственный поток.

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

К сожалению, для лазаруса решение не обновлялось.

Vlad FDmSer,

На каких то еще версиях Delphi оно работает (проверялось) старше 2007-й?

Предыдущая версия проверялась. Новая не проверялась. И как показывает тестирование, не работает :(
Эх, жаль. Если повезёт и найдётся времени, то я разберусь что поломалось.

Vlad FDmSer,

А явное указание LibraryName к ней приделал?

Мой предыдущий пост был про логгер. Он не заработал в D10.2.3. Я про это написал.
Вы уточняйте, о чём спрашиваете.

ibxFBUtils работает в последних версиях Delphi. Насколько стабильно - не знаю. Зависит больше от самих компонентов IBX (они же вроде сейчас - кроссплатформенные, и под Android / IOS / Linux должны работать).
LibraryName я не приделывал. В планах такого не было.
Если Embarcadera решила сделать IBX кроссплатформенными (т.е. вроде не отказываются от их развития), то могли бы догадаться:
1. что реальным разработчикам ПО необходимо иметь 2 транзакции (на чтение и запись). Вариант с одной транзакцией по их логике - это чисто локальные БД без какой-либо гарантии сохранности данных.
2. что многие разработчики (если не большинство) используют IBX для работы с Firebird, поэтому необходимо LibraryName :)
Я уж и не говорю по 64-разрядные приложения.

На самом деле нет никакой проблемы с использованием GDS32.dll для IBX. Достаточно кинуть fbclient.dll, а с ним ещё пяток файлов в папку своей программы (лучше создать под них отдельную папку) и переименовать в GDS32.dll (на самом деле есть несколько вариантов).

Vlad FDmSer,

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

Если Вам что-то непонятно, перечитайте внимательно ещё раз. По-моему, доступно написал.

Кроме того, в новых версиях IBX переименования fbclient в gds32 уже недостаточно, там все осложнилось и допиливание в этой части IBX требует нетривиальных усилий.

Я запускал тесты для Win32 в Delphi Tokyo - вроде заработало. Я в курсе, что с таким подходом (переименование) какой-то функционал IBX не заработает. На этот случай при установке Firebird есть пункт "Создать клиентскую библиотеку для унаследованных приложений", там всё по уму должно быть.


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

Я не буду расстраиваться.