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 (на самом деле есть несколько вариантов).