Есть программа, которая ставится на обычный комп, не в сети. Этой программе требудется хранить достаточно большие объемы с не самой простой структурой.
Трубуется SQL, который будет занимать мало места, не будет требовать установки и регистрации на этом компьютере, т.е. переписали несколько файликов на компьютер и все.
При этом кране желательно работать с этой базой в Delphi через ADO компоненты.

Последние 4 дня я пытаюсь добиться нормальной работы с Firebird.
Но вот добиться с ней работы через ADO не получается.
До этого работали с MSSQL и выработали целую стратегию построения хранимых процедур на сервере и работы с ними из Delphi. Но к сожалению с Firebird это сделать не удалось.

авторSybase SQL Anywhere
Там есть процедуры, в которых я могу передавать параметры, делать Insert, Update, Delete, а также делать SELECT, который вернет мне recordset?

С Fireberd проблемка есть, не все там так гладко. В соответствующем форуме уже на меня вон смотрят косо, даже hvlad и здесь высказался. Хотя весь прикол в том, что работая с Faerbird можно не догадываться, что существуют сервера куда как лучше, и следовательно непонимать проблемы человека, пересевшего с мерса на жигули. :)

В часности для получения из поцедуры селекта в виде dataset там приходится в самом клиенте писать
в то время как в связке ADO + MSSQL есть простой метод

автор> IBQuery.SQL = 'select *from MyProc'

А что в этом плохого? Универсальный, удобный и простой способ. Что
select, что вызов процедуры - все это с точки зрения клиента просто
тексты запросов, посылаемых на сервер.

Клиента пишет один человек, процедурами на сервере занимается другой. Причем друг друга заменить они не могут. Теперь относительно универсальную процедуру решили использовать еще для одной задачи, добавив всего один параметр.
В случае если клиент выполняет запросы ADOStoredProc.Open, перед этим прочитав параметры и заполнив только необходимые, с ним ничего делать не надо, программист не исравляет клиента, не перекомпилирует, не переписывает всем пользователям.
У меня для базы на MSSQL есть формы, которыми пользуются уже который год, не трогая их. В то время как в саму процедуру, используемую ими, уже столько изменений внесли.

Да, сразу отвечаю на вопрос, почему бы для другой задачи не использовать другой запрос. Так появится третий, четвертый, пятый и т.д. А потом потребуется во всех этих процедурах поменять алгоритм расчета. А вот при использовании моей стратегии, вся замена делается в одной процедуре.

Будет ли эта процедура тормозить?
Ну тут если грамотно делать, и в разумных пределах, то все будет очень хорошо работать. Проверяно на достаточно большой базе, которую дерут 24 часа в сутки, 7 дней в неделю, ну может ночью менее интенсивно.

авторЭто и есть главная причина недовольства?
Да, создатель клиента не хочет (и этого не нужно) синхронизировать свою работу с моей. И он не SQL программист.