1. Home
  2. /
  3. Docs
  4. /
  5. Articles Report Writer
  6. /
  7. Database Components
  8. /
  9. FD Components

FD Components

FD Components Overview

Articles uses a set of FireDAC-based data components to connect your reports to databases. These components appear in the report designer and are prefixed with FD. Understanding what each component does and when to use it will help you build reports faster and avoid common mistakes.

What Are FD Components?

FD Components are the bridge between your report and your database. You place them in the report designer, configure them to point at your data, and then bind report bands and objects to them. When the report runs, the components fetch the data and feed it to the report engine.

All FD components are built on FireDAC, Embarcadero’s database access library. FireDAC supports a wide range of databases including SQL Server, MySQL, Actian Zen, and many others. You do not need to know FireDAC to use these components — Articles handles the FireDAC details for you.

The Components at a Glance

FD Database
Defines a connection to your database. All other FD components need an FD Database to know where to connect. You typically have one FD Database per report. See FD Database.

FD Query
Runs a SQL SELECT statement and returns rows to the report. This is the most commonly used component. Use it whenever you need to fetch data from a database table. See FD Query.

FD Table
Opens a database table directly without writing SQL. Useful for simple reports where you need all rows from a single table. See FD Table.

FD MemTable
An in-memory table that holds data during the report run. Unlike FD Query and FD Table, it does not connect to a database directly. You populate it from a file, from script code, or by copying data from another dataset. Use it when you need to accumulate, transform, or carry data across report sections. See FD MemTable.

FD Stored Proc
Calls a stored procedure on your database. Use it when your data logic lives in a stored procedure rather than a plain SQL query. See FD Stored Proc.

Which Component Should I Use?

If you are not sure which component to use, start here:

  • Fetching data with a SQL query → use FD Query
  • Opening a whole table with no filtering → use FD Table
  • Calling a stored procedure → use FD Stored Proc
  • Holding data in memory during the report → use FD MemTable
  • Loading data from a CSV or JSON file → use FD MemTable

Every report that connects to a database also needs at least one FD Database component.

How Components Work Together

A typical report uses components in this order:

  1. FD Database â€” establishes the connection
  2. FD Query (or FD Table) — fetches the data using that connection
  3. Report bands â€” bind to the FD Query to display the data

For reports with a header and detail rows — for example a check with a list of paid invoices — you use two FD Query components linked together using the Master/Detail pattern. The master query fetches the check, and the detail query fetches the invoices for that check. See Master Detail Setup.

Where to Find the Components

All FD components are available in the report designer. Open the designer, look for the data components panel, and you will see FD Database, FD Query, FD Table, FD MemTable, and FD Stored Proc listed there. Drag the component you need onto the designer surface to add it to your report.

A Note on Macros and Parameters

FD Query supports two ways to pass values into your SQL at runtime:

  • Parameters â€” standard SQL parameters using a colon prefix, for example :CustomerID. Use these for filtering values like dates, IDs, and amounts. See Using Parameters.
  • Macros â€” Articles-specific substitution tokens using an exclamation prefix, for example !TableName. Use these when you need to swap out parts of the SQL itself, such as a table name or a column list. See Using Macros.

Documentation Pages

Use the links below to go directly to the page you need:

Articles