FireDAC компоненты

FireDAC: что скрывается за «просто подключился»?

Когда вы впервые сталкиваетесь с FireDAC, кажется, что всё прозрачно: пара компонентов, строка соединения — и данные потекли. Но за 15 лет работы с Delphi я убедился: именно эта видимая простота рождает больше всего скрытых проблем. Давайте разберём те углы, куда редко заглядывают документации и блоги.

Типичная ловушка: TFDConnection и «магические» строки

Большинство разработчиков формируют Connection Definition на лету, указывая драйвер, сервер и учётные данные. Это работает. До поры. Главный риск — именованные определения (Connection Definition Name). Если вы храните их в INI-файле или реестре, рано или поздно столкнётесь с ситуацией, когда на машине пользователя сбит алиас. Решение: используйте FDManager.OpenDef с явным перечислением параметров — это полностью исключает зависимость от внешних конфигов.

1. Укажите параметры прямо в коде: FDConnection.Params.Add('Server=127.0.0.1');
2. Откажитесь от использования DriverID как единственного идентификатора — для FB/IB всегда добавляйте Database и User_Name.
3. Для отладки включите FDConnection.Params.Values['ApplicationName']:='MyApp'; — это спасёт при разборе логов сервера.

Неочевидный нюанс: кэширование TFDQuery

Принято считать, что TFDQuery после Close() освобождает все ресурсы. Это не так. FireDAC удерживает в памяти метаданные результата для ускорения повторных открытий — так называемые Prepared-объекты. На 5-10 запросах вы этого не заметите, но если в цикле меняются сотни SQL-запросов, память начнёт расти. Выход: принудительно вызывать FDQuery.Unprepare перед перезапиской SQL, если запрос гарантированно больше не повторится с такой сигнатурой.

Профессиональный приём: используйте FDQuery.Prepare для тяжёлых пакетных операций, но всегда парно завершайте Unprepare. Для веб-сервисов или многопоточных приложений это критично — утечка незаметна, пока не наступит OutOfMemory.

Миф о «простоте» Array DML

Один из мощнейших механизмов FireDAC — пакетная вставка через Array DML. Миф состоит в том, что достаточно задать массив параметров — и скорость вырастет автоматически. Нюанс: при использовании Array DML FireDAC по умолчанию эмулирует пакетную обработку через обычные INSERT, если СУБД это не поддерживает явно. Реальная экономия — только на СУБД с native bulk-операциями (SQLite, Oracle, MS SQL). Для PostgreSQL или Firebird включайте принудительный режим:

• FDMoniFlatFileClient1.Tracing := True; — чтобы видеть реальные запросы, уходящие на сервер.
• Проверяйте TFDPhysConnection.AdapterRDBMSKind — для FB используйте InsertExec команды, а не массив.
• Маленькая хитрость: перед вызовом Execute для Array DML проверьте FDQuery.ExecuteOptions := FDQuery.ExecuteOptions - [feoBlocked] — иначе вы случайно блокируете главный поток.

Local SQL: когда FireDAC становится умнее драйвера

Не все знают, что FireDAC содержит встроенный синтаксический анализатор — так называемый Local SQL. Он позволяет выполнять SQL-фразы, не поддерживаемые целевой СУБД. Это одновременно и спасение, и ловушка. Например, вы написали LIMIT 10 для MSSQL — FireDAC автоматически перепишет его в TOP 10. Отлично? Да, но если нужно вставить фрагмент с уникальным синтаксисом (скажем, Oracle ROWNUM), Local SQL может исказить запрос. Совет: всегда тестируйте генерацию через FDConnection.ConnectionIntf.CreateDSQL и смотрите сгенерированный текст через FTrace — так вы точно узнаете, как FireDAC интерпретирует ваш SQL.

Обслуживание пула: скрытая настройка Pooling

Пул соединений FireDAC (TFDConnection.Pooling) включается одной галкой. Но магическая настройка, которую игнорируют 90% разработчиков — PooledConnectionID. Если вы не задаёте уникальный идентификатор пула, все приложения с одинаковыми параметрами будут делить один пул. Это приводит к конфликтам в мультитенантной среде. Профессиональный подход:

1. Создайте свой PooledConnectionID на основе хэша имени приложения и версии.
2. Контролируйте параметр MaxPoolSize — не ставьте значения больше 50 без нагрузки; более высокие числа снижают производительность при создании.
3. Для длительных операций (фоновые задачи) лучше использовать отдельный TFDConnection без публикации, чтобы не переполнить пул.

Заключение: взгляд под капот

FireDAC — мощный инструмент, но его «лёгкость входа» обманчива. Уделите внимание настройкам кэширования, пулинга и мониторинга. Самый ценный совет, который я могу дать: никогда не полагайтесь на умолчания в TFDConnection. Каждый проект уникален, и FireDAC даёт все инструменты, чтобы тонко настроить связку под конкретную СУБД и сценарий. Экспериментируйте и используйте FDMonitor — он покажет истинную картину того, что происходит на проводах.

Добавлено: 27.04.2026