FireDAC as a unified data access decision in RadStudio

Shipping the same data access logic to a VCL desktop client and a FireMonkey mobile client while keeping the option to move between SQLite on device and PostgreSQL or SQL Server on the server is a common tension in RadStudio projects. The practical engineering decision is not which database to pick first, but how to isolate connection, command and presentation so the application code does not change when the driver changes.

FireDAC is the database connectivity framework shipped with RadStudio. It presents a single API surface over multiple relational engines through driver‑based connectivity. The architecture separates connection management, command execution and dataset presentation. That separation lets the same data access code target different databases with driver swaps rather than rewrites.

Why the separation matters for desktop and mobile

Connection management in FireDAC is handled by TFDConnection. It owns the driver link, credentials and pooling settings. Command execution is handled by TFDQuery or TFDStoredProc. Dataset presentation is a separate layer that can be bound to UI controls via LiveBindings in VCL and FireMonkey.

Because the layers are distinct, you can keep business logic against TFDQuery parameters and cached updates while the connection points to an embedded SQLite driver for mobile offline use and to a client‑server driver for desktop. Cached updates and local SQL execution are features that can reduce network round trips for mobile and client‑server scenarios by staging changes locally and applying them in batches.

Design‑time integration and a concrete setup

RadStudio exposes FireDAC components in the Component palette under the FireDAC category, with visual Data Modules and a design‑time connection editor. LiveBindings can connect a TFDQuery field to a VCL grid or FireMonkey control without manual data‑aware wiring.

A minimal, edition‑agnostic setup looks like this:

// DataModule with connection and query
object DM
  object FDConnection1: TFDConnection
    Params.Strings = (
      'DriverID=SQLite'
      'Database=:memory:'
    )
    Connected = True
  end
  object FDQuery1: TFDQuery
    Connection = FDConnection1
    SQL.Strings = (
      'SELECT id, name FROM customers WHERE id = :id'
    )
    CachedUpdates = True
  end
end

At design time you would open the connection editor from the TFDConnection properties, choose the driver, and set parameters such as Database path or Server name. Parameter binding uses named parameters like :id, which are driver independent.

To verify the installation in your environment, open RadStudio IDE and inspect the Component palette for the FireDAC category and components such as TFDConnection and TFDQuery. Create a new VCL or FireMonkey application, add a FireDAC connection component, and open the design‑time connection editor to confirm parameter binding is available. Check the installed platforms and SDK managers to confirm which database drivers are available in the current installation.

Trade‑offs and limitations

Feature availability and driver support varies by RadStudio edition and release year, with Professional and Enterprise editions differing in database driver inclusion. Behavior of connection pooling, encryption and mobile deployment profiles is version‑sensitive and may change between major RadStudio releases.

C++Builder and Delphi toolchains share FireDAC but component naming and property editors differ, affecting cross‑language reuse. A Data Module built in Delphi will not paste cleanly into a C++Builder project without adjusting property names and string handling.

Connection pooling and cached updates also add state you must manage. Cached updates require explicit ApplyUpdates and rollback handling. Pooling settings that improve desktop throughput can increase memory use on mobile.

Rollback is only relevant when you change persistent state, such as modifying connection parameters or enabling cached updates on a live dataset. Before changing production connection strings, duplicate the Data Module, test with a non‑production database, and keep the original component properties documented.

Actionable check

Decide on a driver abstraction first, then pick engines. Keep all SQL in TFDQuery objects, avoid driver‑specific syntax, and centralize connection creation in a Data Module. Verify driver presence in SDK Manager, confirm TFDConnection can open with the intended driver in your edition, and test cached updates flow with a small local database before deploying to mobile profiles.