Компонент TFDStoredProc

Самые частые заблуждения при использовании TFDStoredProc

Начинающие разработчики ошибочно воспринимают TFDStoredProc как универсальную замену TFDQuery для вызова хранимых процедур. На деле это узкоспециализированный инструмент, и его слепое применение «на все случаи» — путь к потере контроля над результатами. Я обращаю внимание: наибольшие проблемы возникают, когда программист забывает, что поведение компонента сильно зависит от СУБД за фасадом FireDAC.

• Заблуждение 1: «Мне нужны выходные параметры, значит — только TFDStoredProc». На практике, если процедура возвращает один простой набор данных (SELECT), TFDQuery с ExecSQL зачастую эффективнее и прозрачнее в отладке.
• Заблуждение 2: «Всегда нужно устанавливать StoredProcName явно». Профессионалы знают: FireDAC умеет подтягивать метаданные о параметрах процедуры автоматически через свойство FetchOptions.Items (режим fiMeta). Если вы каждый раз вручную задаёте параметры, вы теряете время и вносите риск рассинхронизации с реальной сигнатурой процедуры.
• Заблуждение 3: «Свойство ParamBindMode — техническая деталь, не влияет на логику». Катастрофическая ошибка: по умолчанию pbByName, но если процедура перегружена (overloaded) именами параметров с разными типами — FireDAC начнёт путаться. Я рекомендую в таких случаях переключаться на pbByNumber и жёстко следить за порядком объявления аргументов.

Неочевидные настройки и «молчаливые» глюки

Когда я вижу в коде TFDStoredProc без настройки ResourceOptions.ParamCreate и MacroCreate, сразу понимаю: разработчик никогда не сталкивался с ситуацией, когда процедура на сервере менялась, а клиент об этом «не знал». FireDAC кэширует метаданные, и если не принудить его перечитывать параметры — получите „Parameter 'X' not found“ при следующем вызове. Совет: для критичных участков используйте ADStoredProc.ParamCreate := False; и явно задавайте Params через коллекцию — это даёт полный контроль.

Ещё один нюанс — работа с возвращаемыми наборами данных через Open vs ExecProc. Новички забывают, что TFDStoredProc наследует от TFDDataSet, и базовая команда .Open срабатывает, даже если процедура не возвращает курсор. Результат — зависание интерфейса или выброс исключения „Cannot open a non-cursor-based stored procedure“. Профессионалы всегда проверяют: if ADStoredProc.IsSelect then ADStoredProc.Open else ADStoredProc.ExecProc;.

Советы эксперта: контроль над памятью и потоками

• Транзакции и автообновление параметров. В FireDAC есть скрытая оптимизация — если вы используете TFDTransaction с Options.AutoCommit, после вызова ExecProc параметры со статусом pdInputOutput сбрасываются автоматически. Это приводит к потере значений, если процедура модифицирует INOUT переменные. Решение: всегда явно копируйте значения из Params до закрытия соединения.
• Производительность при пакетных вызовах. Забудьте про цикл for i := 1 to 1000 do StoredProc.ExecProc;. Используйте TFDStoredProc.Params.ArraySize и метод ExecProc(1, true) с флагом AParamsArraySize. Это превращает последовательные запросы в один пакетный вызов — прирост скорости на SQL Server и PostgreSQL до 20 раз.
• Метаданные vs реальность. Никогда не полагайтесь на FieldDefs до вызова Open или ExecProc. Баги с неверной типизацией полей (например, ftWideString вместо ftString) в FireDAC — следствие того, что СУБД не всегда отдаёт полную метаинформацию до выполнения. Вызов StoredProc.Active := False; StoredProc.Prepare; принудительно обновляет метаданные, но это медленная операция — кэшируйте ее при инициализации модуля.

Специфика для разных СУБД: то, о чём молчат документации

Вот где скрываются настоящие грабли. Разработчики часто пишут код «универсально», и при переключении с MSSQL на PostgreSQL — получают странные ошибки.

1. InterBase/Firebird: Тип возврата через RETURNS в FireDAC транслируется как отдельный набор данных, а не как выходной параметр. Если процедура имеет OUT параметры и курсор — используйте FetchOptions.Mode := fmOneRecord для оптимизации.
2. Oracle: Частая ошибка — привязка к ref cursor. FireDAC требует явного указания StoredProc.CommandKind := skStoredProcWithResult, иначе компонент не увидит курсор, а вернёт только скалярные параметры. Дополнительно: всегда выставляйте ResourceOptions.MacroCreate := False — макросы взаимодействуют с PL/SQL конфликтуют с ref cursor.
3. MSSQL: Вложенные процедуры с WITH RECOMPILE приводят к тому, что FireDAC игнорирует свойство Prepared и каждый раз заново парсит метаданные. Оптимальный способ: кешировать параметры вручную и обходить вызов Prepare.

Итоговый профессиональный совет: TFDStoredProc — мощный, но капризный инструмент. Не используйте его как «чёрный ящик». Всегда тестируйте на целевой СУБД с реальными данными, отключайте автоматическое управление параметрами, где это критично, и помните: в 70% случаев TFDQuery с явным SQL даёт больше предсказуемости, а TFDStoredProc оправдан лишь тогда, когда структура процедуры меняется динамически или требуется глубокое использование специфики СУБД (например, временные таблицы внутри процедуры).

Добавлено: 27.04.2026