Table Input

Description

The Table Input transform is one of the most frequently used transforms in Apache Hop. It reads data from a relational database using a connection and an SQL query, and introduces that data into a pipeline.

This transform supports parameterization using:

Apache Hop variables (e.g., ${customerId})
Named input fields from a previous transform (JDBC prepared statements using {fieldName} placeholders)
Positional input fields from a previous transform (JDBC prepared statements using ? placeholders)

The dialog is split into SQL, Options, and Fields tabs.

These features make Table Input ideal for dynamic and reusable data retrieval logic.

Supported Engines

Hop Engine

Supported

Single Threaded

Supported

Native Spark

Supported

Beam Spark

Supported

Beam Flink

Supported

Beam Dataflow

Supported

Getting Started: Generate a Basic SQL Query

You can auto-generate a query using the Get SQL select statement button.

This opens the database explorer, allowing you to select a table or view. Once selected, you can choose to generate:

A full column list: SELECT col_a, col_b, col_c FROM my_table;
A wildcard query: SELECT * FROM my_table;

Use Fields from a Previous Transform

Incoming hops are parameter sources. Table Input reads all of them, not only the transform named in Insert data from transform. Parameter rows are never copied to the output; only the SQL result is.

Insert data from transform is optional. When you select a transform there, that hop is informational (the usual Hop info hop used for lookup-style data). You can leave it empty and still bind parameters from any incoming hop. Enabling Use named parameters turns on Execute for each row when hops exist and, when there is a single incoming hop, fills Insert data from transform for you.

Prefer named parameters {fieldName} so the SQL does not depend on incoming field order. Enable Use named parameters on the SQL tab (on by default for new transforms, off when opening existing Table Input metadata). Use Insert field… to pick an incoming field and insert {fieldName} at the cursor.

Execute for each row is the usual case: run the query once per incoming row. Disable it only for the legacy assemble-all path, where every incoming row is concatenated into one parameter list. That is how positional SQL such as WHERE bar IN (?,?,?) can be filled from three one-field rows.

If two hops into Table Input have different layouts, Hop still warns about mixing rows. That check is unchanged.

Named parameter with an informational hop from the previous transform:

Table Input using named parameter segment from an informational hop

SELECT *
FROM public.tableinput
WHERE id > {openfield}id{closefield}
  AND changed_date >= {openfield}fromDate{closefield};

Named parameters:

Are opt-in so existing SQL that already uses curly braces is left unchanged
Bind by incoming field name (case-insensitive)
Can be used more than once
Ignore extra incoming fields
Cannot be mixed with positional ? in the same statement
Do not conflict with Hop variables ${variable}
Work best with a single parameter row, or with Execute for each row

Classic positional ? placeholders remain supported. Values are passed in the order of fields in the incoming stream. Use a Select Values transform to ensure the correct field order if you use ?.

Prepared statements:

Improve security by preventing SQL injection
Cannot parameterize all parts of a SQL statement (e.g., IN (?) or table names)

You can also combine named or positional parameters with variable substitution.

Sample pipeline: tableinput-named-parameters.hpl

Examples

Parameterized query using input fields:

Parameterized query using input fields

SELECT *
FROM public.tableinput
WHERE id > ?;

Replace variables in script: unchecked
Insert data from transform: optional; select the previous transform to mark the hop as informational, or leave empty if a hop is already connected

Sample pipeline: tableinput-accept-input.hpl

Using a date range from a system transform:

Using a date range from a system transform

SELECT *
FROM public.tableinput
WHERE changed_date BETWEEN ? AND ?;

Use a Get System Info transform to generate the start and end dates
Insert those dates using Insert data from transform

Use Variables in Your SQL Query

If your query includes Hop variables, enable Replace variables in script. This performs a simple string replacement before the query is sent to the database.

SELECT *
FROM public.tableinput
WHERE id > {openvar}PRM_ID{closevar};

${PRM_ID} is defined as a pipeline variable (e.g., via parameters or Set Variables transform)

Parameter definition in pipeline

This gives you full control over the query structure
Combine with ? placeholders if needed

Variable substitution happens before execution and does not protect against SQL injection.

Replace variables in script: checked
Insert data from transform: leave empty

Sample pipeline: tableinput-variables.hpl

Using Both Variables and Prepared Statements

You can combine both techniques in a single query:

Using Both Variables and Prepared Statements

SELECT *
FROM public.tableinput
where id > {openvar}PRM_ID{closevar} AND lastdate > ?;

${startDate} is a pipeline variable
? is a parameter provided by the input stream

Best Practices and Pro Tips

Pro Tips

The Table input transform does not pass input data to the output, only fields inside the query are returned to the pipeline so all other variables and data will be lost. You can solve this by adding the variable as a field in the query or put a Get variables transform behind the table input.

If you are getting unexpected query results, try clearing the database cache. Click the broom icon or go to Tools > Clear DB Cache. After clearing, click OK, save your pipeline, and reopen it if needed.

A cartesian join transform will combine a different number of fields from multiple table inputs without requiring key join fields.

When Execute for each row is off, Table Input waits until every incoming hop has completed so it can concatenate the parameter rows.

For better performance with large datasets you can use indexed columns in WHERE clauses and avoid SELECT * and only retrieve needed fields.

Dynamic SQL with Metadata Injection

Table Input can be used in a metadata-driven pipeline. For example, create a template pipeline with a generic query:

SELECT *
FROM {openvar}tableName{closevar}
WHERE {openvar}condition{closevar}

Then use a Metadata Injection transform to inject actual values (e.g., from a CSV or database).

Steps:

Create a template pipeline with Table Input
Use ${tableName} and ${condition} as placeholders
In a separate pipeline, use Metadata Injection to inject values into the SQL field
Execute the injected pipeline

This allows you to create reusable and dynamic pipelines without editing SQL manually.

You can inject metadata into the following fields of the Table Input transform:

Connection
SQL
Replace variables in script?
Insert data from transform
Execute for each row?
Limit size
Use named parameters
Specify output fields
Validate specified fields
Output field name, type, format, length, and precision

Preview

The Preview button opens a dialog where you set how many rows to fetch and a query timeout in seconds (JDBC Statement#setQueryTimeout).

The timeout applies only while the pipeline is running in preview mode from the Hop GUI (not during a normal pipeline run from a run configuration or Hop Run).
You can set a default for the timeout field with the HOP_QUERY_PREVIEW_TIMEOUT application variable (0 = no default from the variable). When the variable is 0 or unset, the dialog still suggests 5 seconds for the initial value.

Specify output fields

On the Fields tab you can define the output schema instead of asking the database for column metadata. This is the offline design case: developers without database access can still build the pipeline, while Hop Server (or another runtime) executes the query later.

Specify output fields: use the field list as the transform output (name, type, length, precision, format). Get fields can still fill the list from the query when a connection is available.
Validate specified fields: after the query runs, compare the result columns with the specified list. The transform fails if a specified field is missing or the Hop types do not match. Extra columns returned by the query are ignored. When validation is off, missing specified fields still fail (they cannot be mapped) and type differences are converted.

Options

Option Description

Option	Description
Transform name	Name of the transform instance.
Connection	Database connection to execute the query against.
SQL tab	SQL statement, optional SQL file, `Get SQL select statement`, `Use named parameters`, and `Insert field…` for `{fieldName}`.
Use named parameters	When enabled, `{fieldName}` in SQL is bound to an incoming field. Off for existing Table Input metadata, on for new transforms. Disable if curly braces are used for something else. Checking this option also enables Execute for each row when hops exist, and selects the incoming transform when there is only one.
Replace variables in script?	Enable to substitute variables (e.g., `${param}`) in your SQL before execution.
Insert data from transform	Optional. Names the hop that should be treated as informational (parameter rows, not the SQL result). Parameter values are read from all incoming hops. Leave empty when you only need the connected hops as parameter sources.
Execute for each row?	When incoming hops exist, run the SQL query once for each incoming row. Disable to concatenate all incoming rows into a single parameter list (legacy `WHERE bar IN (?,?,?)` from several one-field rows). Incoming hops with different layouts still produce the mixed-layout warning.
Limit size	Maximum number of rows to return from the query. `0` means no limit. See Limit size vs. SQL LIMIT below.
Specify output fields	Define the output field list instead of reading column metadata from the database.
Validate specified fields	When specifying fields, fail if the query result names or types do not match the list.

Transform name

Name of the transform instance.

Connection

Database connection to execute the query against.

SQL tab

SQL statement, optional SQL file, Get SQL select statement, Use named parameters, and Insert field… for {fieldName}.

Use named parameters

When enabled, {fieldName} in SQL is bound to an incoming field. Off for existing Table Input metadata, on for new transforms. Disable if curly braces are used for something else. Checking this option also enables Execute for each row when hops exist, and selects the incoming transform when there is only one.

Replace variables in script?

Enable to substitute variables (e.g., ${param}) in your SQL before execution.

Insert data from transform

Optional. Names the hop that should be treated as informational (parameter rows, not the SQL result). Parameter values are read from all incoming hops. Leave empty when you only need the connected hops as parameter sources.

Execute for each row?

When incoming hops exist, run the SQL query once for each incoming row. Disable to concatenate all incoming rows into a single parameter list (legacy WHERE bar IN (?,?,?) from several one-field rows). Incoming hops with different layouts still produce the mixed-layout warning.

Limit size

Maximum number of rows to return from the query. 0 means no limit. See Limit size vs. SQL LIMIT below.

Specify output fields

Define the output field list instead of reading column metadata from the database.

Validate specified fields

When specifying fields, fail if the query result names or types do not match the list.

Limit size vs. SQL LIMIT

There are two different ways to restrict how many rows Table Input returns. They are not equivalent.

Limit size (client-side, JDBC)

The Limit size option is applied through the JDBC API (Statement#setMaxRows / PreparedStatement#setMaxRows) after the statement is created. Hop does not rewrite your SQL to add a database-specific LIMIT, TOP, or ROWNUM clause for this option.

That means:

Enforcement depends on the JDBC driver and database.
When the driver honors setMaxRows, excess rows are typically dropped on the client side (the database may still produce a larger result set before the driver stops returning rows).
Some drivers and engines do not implement setMaxRows reliably, or ignore it. This is common with certain Generic connections and query engines (for example Dremio). In those cases, Limit size may have no effect even when set to a positive value.
A few database types in Hop explicitly report that they do not support setMaxRows (for example Redshift). For those, Limit size is not applied via JDBC.

When you run the same pipeline under a Pipeline Executor (or any setup that uses different connections or SQL per iteration), a limit that works on one connection may be ignored on another if the second connection’s driver does not honor setMaxRows.

SQL LIMIT (server-side)

For a limit that the database applies while executing the query, put the dialect’s limit syntax in the SQL itself, for example:

SELECT col_a, col_b
FROM my_table
WHERE status = 'ACTIVE'
LIMIT 100;

Other dialects use different syntax (TOP, FETCH FIRST, ROWNUM, and so on). Use what your database supports.

Server-side limiting is usually preferable when you need a reliable cap, better performance on large tables, or when you use a Generic connection / engine that may ignore JDBC setMaxRows.

Recommendation

Goal Prefer

Goal	Prefer
Quick, approximate row cap with a well-behaved JDBC driver	Limit size in the transform
Reliable, portable, or performance-sensitive limit	`LIMIT` / dialect equivalent in the SQL
Generic connection, Dremio, or any driver that ignores `setMaxRows`	Always use a SQL limit clause

Quick, approximate row cap with a well-behaved JDBC driver

Limit size in the transform

Reliable, portable, or performance-sensitive limit

LIMIT / dialect equivalent in the SQL

Generic connection, Dremio, or any driver that ignores setMaxRows

Always use a SQL limit clause

You can combine both: keep a SQL LIMIT for server-side control, and optionally set Limit size as an additional client-side safety net where the driver supports it.