In JMeter's JDBC Request, what variables does a Variable Names value of A,,C create?

middleshould knowfreq 49%

answer

Position in the list, not column names
An empty entry means skip a column
Each name gains a row-count companion
Old rows are cleaned up between samples

basics

~20 s

One numbered variable per row for each named column, plus a row count. For a two-row, three-column select: A_1 and A_2 from column one, C_1 and C_2 from column three, and A_# and C_# both holding 2. The empty entry skips column two.

solid answer

~50 s

Variable Names on a JDBC Request is a positional, comma-separated list: the first entry names column one of the result set, the second names column two, and so on. An empty entry means "skip this column". For each named column JMeter writes one variable per row, suffixed _1, _2, … in row order, and one variable suffixed _# holding the number of rows processed. So A,,C against a select returning two rows of three columns produces A_#=2, A_1, A_2, C_#=2, C_1, C_2 and nothing for column two. A select returning zero rows still sets A_# and C_# to 0 and writes no numbered variables. JMeter also cleans up after itself: if an earlier sample in the same thread wrote six rows and the next writes three, the leftover _4 to _6 variables are removed rather than left holding stale values.

`Variable Names` on a JDBC Request is a positional, comma-separated list: the first entry names column one of the result set, the second names column two, and so on. An empty entry means "skip this column". For each named column JMeter writes one variable per row, suffixed `_1`, `_2`, … in row order, and one variable suffixed `_#` holding the number of rows processed. So `A,,C` against a select returning two rows of three columns produces `A_#=2`, `A_1`, `A_2`, `C_#=2`, `C_1`, `C_2` and nothing for column two. A select returning zero rows still sets `A_#` and `C_#` to `0` and writes no numbered variables. JMeter also cleans up after itself: if an earlier sample in the same thread wrote six rows and the next writes three, the leftover `_4` to `_6` variables are removed rather than left holding stale values.

code

text · 14 lines

text

Variable Names: A,,C
SQL Query     : select id, region, amount from orders_summary

-- select returns 2 rows of 3 columns:
A_#=2 (number of rows)
A_1=column 1, row 1
A_2=column 1, row 2
C_#=2 (number of rows)
C_1=column 3, row 1
C_2=column 3, row 2

-- select returns 0 rows:
A_#=0
C_#=0

go deeper

for a junior

Recall the shape of what is written: one variable per row per named column with a numeric suffix, plus a _# variable holding the row count.

for a middle

Explain that the list is positional so an empty entry skips a column, and that the count variable is set even when the query returns nothing.

for a senior

Show that you check _# rather than the presence of a numbered variable, and that you know JMeter prunes surplus variables when a later result set is shorter than an earlier one.

for a principal

Decide the team's convention for moving result rows around a plan - narrow named columns versus the list-of-maps object - so plans stay readable and do not carry more per-row variables than they use.

Variable Names is how a JMeter JDBC Request hands a result set to the rest of the thread, and its contract is entirely positional.

The naming contract

The field is split on commas. Position i in the list names column i of the result set — not a column by its label, and not in the order you happen to prefer. An empty position skips that column. For each name that is not empty, JMeter writes:

name_1, name_2, … name_n — the column's value in row 1, row 2, … row n, in the order the driver returned them;
name_# — the number of rows that were processed.

Given the list A,,C and a select returning two rows of three columns, the thread ends up holding exactly six variables:

A_#=2   (number of rows)
A_1=column 1, row 1
A_2=column 1, row 2
C_#=2   (number of rows)
C_1=column 3, row 1
C_2=column 3, row 2

Edge cases worth knowing

Zero rows. A_# and C_# are set to 0 and no numbered variables are written at all. The count variable always exists after the sampler runs, which makes it the thing to test rather than the presence of A_1.
Shrinking result sets. If a previous sample in the same thread set A_1…A_6 and this one returns three rows, JMeter reads the previous A_#, removes A_4, A_5 and A_6, and then writes the new count. Without that cleanup a shorter second query would leave the tail of the first one visible.
More names than columns. A name past the last column gets no numbered variables — but it still gets its _# count variable, set to the row count like every other name in the list. So a surplus name's _# will look healthy even though no value was ever written under it.
Callable statements. The same field is reused for OUT parameters, and there the list must be in the same order as the OUT parameters returned by the call. Extra names are ignored; too few names means only that many results are stored.
Values are strings. Numbered variables hold the column value's string form. A byte-array column is decoded as UTF-8 before it is written.

Variable Names versus Result Variable Name

The sampler offers a second, quite different way to hold the rows.

	`Variable Names`	`Result Variable Name`
What is written	one flat string variable per row per named column	one object variable
Shape	`A_1`, `A_2`, …, `A_#`	a list of maps, one map per row
Keyed by	position in the comma-separated list	the column label from the result set
Read with	ordinary `${A_1}` references	`vars.getObject("resultObject").get(0).get("Column Name")` from a script element

They are not exclusive; setting both fills both. The list-of-maps form is the one to reach for when the column set is wide or when downstream logic wants to look a value up by column name instead of by position.

What this field does not control

Two misconceptions are worth naming. First, Variable Names does not limit what the sampler reads: the JDBC Request walks the whole result set and builds the sample's response data from every row whether or not you named a single column, so leaving the field blank saves you variables, not work. Second, Handle ResultSet — with its Store as String, Store as Object and Count Records options — governs values of ResultSet type coming back from callable statements; it is not a switch that changes how an ordinary select fills these numbered variables.

Practical checks

Count the commas, not the names — a leading or doubled comma shifts every following name onto a different column.
Assert on name_# when you need to know a query returned anything; it is set even when the answer is zero rows.
Watch for a ${A_1} that renders literally as ${A_1} in a later field: an unresolved reference is not blank, so a literal ${A_1} in a request body means the variable was never written, not that it was written empty.
If the query is wide and you only need one column, name only that column — every extra name costs one variable per row.

`Variable Names` is how a JMeter JDBC Request hands a result set to the rest of the thread, and its contract is entirely positional. ## The naming contract The field is split on commas. Position **i** in the list names column **i** of the result set — not a column by its label, and not in the order you happen to prefer. An empty position skips that column. For each name that is not empty, JMeter writes: - `name_1`, `name_2`, … `name_n` — the column's value in row 1, row 2, … row n, in the order the driver returned them; - `name_#` — the number of rows that were processed. Given the list `A,,C` and a select returning two rows of three columns, the thread ends up holding exactly six variables: ``` A_#=2 (number of rows) A_1=column 1, row 1 A_2=column 1, row 2 C_#=2 (number of rows) C_1=column 3, row 1 C_2=column 3, row 2 ``` ## Edge cases worth knowing - **Zero rows.** `A_#` and `C_#` are set to `0` and no numbered variables are written at all. The count variable always exists after the sampler runs, which makes it the thing to test rather than the presence of `A_1`. - **Shrinking result sets.** If a previous sample in the same thread set `A_1`…`A_6` and this one returns three rows, JMeter reads the previous `A_#`, removes `A_4`, `A_5` and `A_6`, and then writes the new count. Without that cleanup a shorter second query would leave the tail of the first one visible. - **More names than columns.** A name past the last column gets no numbered variables — but it still gets its `_#` count variable, set to the row count like every other name in the list. So a surplus name's `_#` will look healthy even though no value was ever written under it. - **Callable statements.** The same field is reused for `OUT` parameters, and there the list must be in the same order as the `OUT` parameters returned by the call. Extra names are ignored; too few names means only that many results are stored. - **Values are strings.** Numbered variables hold the column value's string form. A byte-array column is decoded as UTF-8 before it is written. ## Variable Names versus Result Variable Name The sampler offers a second, quite different way to hold the rows. | | `Variable Names` | `Result Variable Name` | |---|---|---| | What is written | one flat string variable per row per named column | one object variable | | Shape | `A_1`, `A_2`, …, `A_#` | a list of maps, one map per row | | Keyed by | position in the comma-separated list | the column label from the result set | | Read with | ordinary `${A_1}` references | `vars.getObject("resultObject").get(0).get("Column Name")` from a script element | They are not exclusive; setting both fills both. The list-of-maps form is the one to reach for when the column set is wide or when downstream logic wants to look a value up by column name instead of by position. ## What this field does not control Two misconceptions are worth naming. First, `Variable Names` does not limit what the sampler reads: the JDBC Request walks the whole result set and builds the sample's response data from every row whether or not you named a single column, so leaving the field blank saves you variables, not work. Second, `Handle ResultSet` — with its `Store as String`, `Store as Object` and `Count Records` options — governs values of `ResultSet` type coming back from callable statements; it is not a switch that changes how an ordinary select fills these numbered variables. ## Practical checks 1. Count the commas, not the names — a leading or doubled comma shifts every following name onto a different column. 2. Assert on `name_#` when you need to know a query returned anything; it is set even when the answer is zero rows. 3. Watch for a `${A_1}` that renders literally as `${A_1}` in a later field: an unresolved reference is not blank, so a literal `${A_1}` in a request body means the variable was never written, not that it was written empty. 4. If the query is wide and you only need one column, name only that column — every extra name costs one variable per row.

What does the Result Variable Name field give you that Variable Names does not?
An object variable holding a list of row maps, one map per row, keyed by the result set's column labels rather than by position. A script element reads it as `vars.getObject("resultObject").get(0).get("Column Name")`. It suits wide result sets and lookups by column name, where the numbered variables suit a handful of named columns.
A JDBC Request returns fewer rows than the previous one in the same thread. What happens to the surplus variables?
They are removed. Before writing the new count, JMeter reads the previous `name_#`, deletes every `name_i` above the new row count, and only then stores the new `name_#`. Without that cleanup the tail of the earlier result would still be readable and would look like current data.

saying these in an interview costs you the question

Thinks the names match result set column labels
Forgets the _# row-count variable entirely
Assumes an empty list entry is an error
Believes stale row variables survive the next sample
Expects a missing variable to resolve to an empty string

In JMeter's JDBC Request, what variables does a Variable Names value of A,,C create?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

The naming contract

Edge cases worth knowing

Variable Names versus Result Variable Name

What this field does not control

Practical checks

▾common follow-ups2 questions

▾red flags5 flags

The naming contract

Edge cases worth knowing

Variable Names versus Result Variable Name

What this field does not control

Practical checks

answer

go deeper