Простейшее тестовое приложение Lazarus + IBX (FireBird Express), в котором для вставки и редактирования записи в запросах используется EXECUTE BLOCK, проверка корректности вводимых значений так-же вынесены в EXECUTE BLOCK.
Запрос c EXECUTE BLOCK на добавления записи использует выражение RETURNING для возврата значения первичного ключа полученного в триггере, которое автоматически, сразу после выполнения запроса подставляется в локальный кэш IBDataset. В примере показано как использовать свойство TIBDataSet.OrderFields для задания сортировки (метод сортировки не работает с локальным кэшем набора данных, а парсит и изменяет/добаляет инструкцию ORDER BY в SELECT).
Кроме этого пример показывает, как перехватить обработку исключений в приложении для замены дурацкого окна сообщений об ошибках на свое собственное, одновременно в обработчике исключений перехватываются сообщения об ошибках FireBird, сгенерированные в хранимых процедурах, триггерах, для вывода их в нормальном виде.
http://visual-t.ru/files/IBTest2.7z

Для работы приложения требуется установленный SQL сервер FireBird версии 2.5 либо библиотека локального доступа fbembed.* версии 2.5.
Перед сборкой тестового приложения в редакторе компонента IBDatabase1 требуется прописать путь к базе TESTDB.FDB (лежит в папке с проектом) и путь к клиентской библиотеке FireBird, прописать логин и пароль.
Клиентская библиотека в комплекте поставки отсутствует.

Сами модифицированные компоненты IBX for Lazarus можно найти здесь:
http://visual-t.ru

Основные изменения:
Изменения в организации доступа к API FireBird. В оригинальной версии, независимо от того какое количество компонентов
TIBDataBase используется в программе, существовал единый метод загрузки клиентской библиотеки, а это значит, что
работа из программы была возможна только с серверами одной и той же версии, нельзя было загрузить 2 разные
клиентские библиотеки. Работа с компонентами была возможна, только если предварительно удалось загрузить клиентскую
библиотеку. Каждый компонент TIBDatabase получил персональный механизм доступа к клиентской библиотеке, загрузка библиотеки происходит при установлении соединения с базой, при разрыве соединения, библиотека освобождается.
В компонент TIBDatabase добавлено свойство LibraryName - в котором указывается имя библиотеки. Поиск и загрузка
библиотеки происходит исключительно по указанному имени. Имя может быть указано с полным путем и без. Если
путь не указан, поиск библиотеки происходит в папке с выполняемой программой. В свойстве LibraryName
по умолчанию присутствует строка: Для windows - 'fbclient.dll', для Linux - 'fbclient.so'.

TIBDataSet работает в рамках 2х транзакций, пишущей и читающей. Добавлены свойства для автозапуска и автозавершения транзакций, добавлено авто форматирование, эмуляция Boolean полей, автотримирование строковых полей, поддержка Returning Field и возвращаемых значений из Execute Procedure в обновляющих запросах TIBDataSet (возвращаемые значения подставляются автоматом в редактируемую запись после выполнения запроса InsertSQL или ModifySQL), поддержка выражений Execute Block, сортировка (сортировка выполняется не на клиенте в кэше, а парсится и изменяется запрос SELECT, в котором добавляется или изменяется инструкция ORDER BY и запрос переоткрывается), и многое другое.

DarkMasterZeroMQ,

Конкретные вопросы - кокретные ответы.
На текущий момент (имхо) ИБО поддерживает все фичи FB 2.5.x (частично 3.0) и IB XE3.

А вообще, конечно послушать полезно, чего там хорошего, чтобы знать в какую сторону дальше двигаться. Я знаю что IBO хорошо контролирует транзакции чтобы избежать застревание OAT. Интересно было бы знать как датасеты работают с транзакциями. Какое управление транзакциями в IBO?

DarkMasterIBO всегда распространялся одним пакетом. Который включает в себя Core+Native+Tools+Dataset+AddOns.

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

DarkMasterЕсть одна фишка - если в приложении нет транзакций (ну не озадачился программер) - IBO поднимает свою внутреннюю (Default) транзакцию (она контролируется самим обьектом соединения). Сделано было для облегченного перехода с тех БД (ну там какой-нить древний DBF), где про транзакции либо вообще ничего не знали, либо не придавали значения.
Это не фишка - это костыль от недопрограммистов, таких лучше вообще к делу не допускать.
DarkMasterНу и как в лучших домах Лондона и Парижа - отдельные транзакции для чтения/записи.

Транзакции в IBX

В тестовом приложении вы можете увидеть 2 TIBTransaction - IBRead и IBWrite.
IBRead - читающая транзакция, ей заданы параметры:

авторread
read_commited
rec_varsion
nowait

С такими параметрами транзакция стартует в режиме только чтение, не создает версии записей, соответственно не оказывает ни какого влияния на работу сервера и поэтому может жить сколь угодно долго. Сделайте такую-же в своем приложении и все что нужно читать, читайте через неё, т.е. у всех TIBDataSet.Transaction должно быть IBRead. У меня эта транзакция всегда открыта, я стартую её руками после подключения к базе данных, и завершаю руками при закрытии приложения. В противном случае, если читающую транзакцию не держать всё время открытой, это буде приводить к тому, что если понадобится повторно открыть Select запрос, который уже ранее открывался, то у него буде всё время вызываться метод Prepare перед каждым открытием запроса Select, что приведет к сбросу списка параметров и их значения каждый раз нужно будет устанавливать по новой.
Пример:







IBWrite - пишущая транзакция, ей заданы параметры:
авторwrite
wait
no_rec_version
read_commited
lock_timeout = 10

Я использую такую транзакцию для всех коротких пишущих запросов, для TIBDataSet, TIBStoredProc, TIBQuery с опцией AutoCommit := True. Т.е. для всех TIBDataSet в своем приложении, у которых AutoCommit = True (включено по умолчанию) назначьте в свойстве UpdateTransaction - IBWrite. Пишущая транзакция будет сама стартовать и завершаться во время метода Post или Delete.

Частные случаи.
Иногда нужно в рамках одной транзакции записать блок записей в одну или несколько таблиц, и в случае ошибки, для сохранения логической целостности данных, откатить транзакцию, вернув всё в исходное состояние. Для таких случаев, стоит завести отдельную пишущую TIBTransaction. У всех компонент, которые будут её использовать поставить AutoCommit = False. Запускать транзакцию и подтверждать (откатывать) её нужно будет вручную.




Master-detail
Механизм master-detail существенно переработан и жизнь облегчает значительно. Обратите внимание на DetailCondition - используется для управления detail в связке с мастер. В нем если включен dcForceOpenClose - открывает detail автоматически при открытии master и автоматически закрывает его при закрытии master. Если включен dcForceMasterRefresh - вызывает у master.Refresh после detail.Post или detail.Delete. Если включен dcForceMasterPost - то в момент detail.BeforeInsert или detail.BeforeEdit проверяет, если master.State in [dsInsert, dsEdit] то делает ему master.Post.

ZeroMQ-Rik-...
С такими параметрами транзакция стартует в режиме только чтение, не создает версии записей, соответственно не оказывает ни какого влияния на работу сервера и поэтому может жить сколь угодно долго...

А как же "временные" блобы? :)
Кто мешает работу с блоб организовать в отдельной транзакции, которая не будет висеть долго?

kdv-Rik-IBWrite - пишущая транзакция, ей заданы параметры:
write
wait
no_rec_version
read_commited

вы в курсе опции no_rec_version? если у вас эта транзакция пишущая, то зачем ей дэдлоки на ЧТЕНИИ не-committed версий?

У меня нет возможности проводить исследования, я использовал исследования devrace:
http://www.devrace.com/ru/fibplus/articles/2169.php
Я с ними согласен, у меня не было проблем с этим. Параметры к транзакции не гвоздями прибиты, если кто-то считаете что есть лучший вариант, ради бога, но то что я описал, по моему опыту, работает хорошо.

kdv-Rik-С такими параметрами транзакция стартует в режиме только чтение, не создает версии записей, соответственно не оказывает ни какого влияния на работу сервера и поэтому может жить сколь угодно долго
То, что вы написали, неверно. транзакция read read_committed завершена сразу после старта (в IB 6 и выше), поэтому она не является активной, и не удерживает версии записей, созданные другими транзакциями.

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

kdv-Rik-Кто мешает работу с блоб организовать в отдельной транзакции, которая не будет висеть долго?
получается, и тут вы тоже не в курсе.
http://www.ibase.ru/devinfo/dbgrowth.html
никто не запрещает в read read_committed вызовый функции list или конкатенацию блобов. При этом, не смотря на опцию read транзакции, временные блобы будут создаваться именно в этой транзакции.
Про блобы я не знал, учту на будущее.

dedRastaПопробовал переписать программку на Delphi с использованием Lazarus 2.0 и столкнулся с проблемой при сортировке данных по щелчку на заголовке в гриде.

В Delphi (fibplus) я использовал для этого локальную сортировку набора данных.
В Lazarus в Компонентах IBX версия 2.2.8 ( http://www.visual-t.ru) я этого метода не нашел, зато нашел свойство OrderFields.
Если набор данных без параметра, то все получается:

Но если набор данных связать с мастером по параметру
то при щелчке по заголовку выдает ошибку EIBClientError: Empty Query

БД - Firebird 2.5.8.27089
OrderFields добавлялось для TIBDataSet, попробуйте IBQuery заменить на IBDataSet.

Мимопроходящий23.04.2019 18:26, -Rik- пишет:

> OrderFields добавлялось для TIBDataSet

почему не для TIBCustomDataSet ?

Оно добавлено в TIBCustomDataSet, но планировалось для работы только в TIBDataSet, в TIBQuery я его даже не тестировал, можно допилить конечно..

dedRasta-Rik-OrderFields добавлялось для TIBDataSet, попробуйте IBQuery заменить на IBDataSet.

Когда уже уходил с работки, попробовал - та же ошибка
Попробуйте RefreshSQL заполнить.