Why can’t a bound SQLite parameter stand in for a table name?

A parameter is a slot for a value, not a blank space where SQLite inserts SQL words. The statement’s structure is prepared first; binding supplies values for its placeholders afterward. In SQLite’s C interface, parameters can occupy places where literal values are allowed, but not positions for table or column names. [S1]

So in SELECT * FROM ?, SQLite does not treat the bound text as a table identifier. The statement needs its table name in the SQL structure before values are bound. Think of parameters as filling in answers on a form, not changing its labels.

Keep the permitted choices under application control. Map each supported choice to a known SQL statement or identifier, and bind user-supplied values—such as a row ID—as parameters. SQLite’s C interface guidance recommends choosing from controlled valid statement or identifier options for a variable table choice, while binding ordinary data values separately. [S1]

For example, suppose an application offers reports for orders and returns. It could map each report choice to one of two statements written in the application, with a WHERE placeholder for a value such as a record ID. The chosen statement contains its table name; the data value is bound afterward. This is an illustrative pattern, not a guarantee about every programming-language wrapper.

If a table choice must be assembled into SQL text, first resolve it to an exact identifier from a fixed, approved mapping—not directly from arbitrary input. Keep that identifier separate from values that can be bound. Quoting an identifier and binding a value are different operations. The cited material establishes that a bound parameter cannot serve as a table or column name, but does not specify quoting rules or a universal quoting method for every wrapper. [S1][S2]

A reviewable pattern is report choice → fixed statement; if the choice is not in the mapping, do not construct a statement from it. For language-specific quoting, placeholder syntax, or binding calls, consult that wrapper’s documentation. The cited binding page describes the C API and notes that other bindings may have API-specific details. [S2]

Trace both inputs from where they enter the application to where the SQL is prepared. Confirm that the table choice resolves only to an approved statement or identifier, while ordinary values use the binding API. In SQLite’s C interface, host parameters are placeholders in SQL text whose values are supplied through sqlite3_bind_*() routines; documented forms include ?, ?NNN, :VVV, @VVV, and $VVV. [S2]

Check the documentation and tests for the application’s language wrapper too. A useful test plan covers each approved table choice, an unsupported choice, and representative bound values. The cited guidance does not establish how every wrapper behaves or provide a universal identifier-quoting rule, so verify those details in the relevant API documentation.