Build a database results display array by checking the control interface, preserving row and column order, and converting each field through its expected native type before formatting. Keep typed records and stable identifiers separate from the visible strings so sorting, selection and refreshes remain consistent.
Convert database results into the array type the display control expects, without changing the meaning or position of each field. For a two-dimensional variant result feeding a string-based table, that usually means converting each cell to its expected native type, formatting it, and building a two-dimensional string array. Keep the original typed records and their identifiers separate. Before converting anything, confirm that you are writing to the control’s cell-content interface rather than its selection value.
Check what the control accepts
A control that looks like a table does not necessarily accept table data through its main value. Some list controls use their value for the selected row, while a separate property holds the visible cells. Wiring query results to the selection interface will not populate the table.
Read the control documentation and distinguish these interfaces:
| Interface | What it represents | What to supply |
|---|---|---|
| Cell-content property | Visible rows and columns | The documented array type and dimensions |
| Selection value | Selected row or rows | Selection indexes or the documented selection representation |
| Column headings | Labels above the data | Labels matching the displayed field order |
| Application record mapping | The record behind each displayed row | Stable identifiers retained separately from formatted text |
For a multicolumn listbox that documents ItemNames as its cell-content property, write the two-dimensional string array there. A table control may instead accept cell strings through its main value. Check the actual control rather than transferring assumptions between visually similar controls.
Also check whether the control expects rows first or columns first. Correct data in the wrong orientation can look like a conversion failure.
Separate query status from array shape
A blank table does not identify the fault. The query may have failed, returned no matches, or produced values that the display adapter could not convert. Check those conditions separately.
Before inspecting formatting, examine:
- Query status: Did the connection, execution and fetch operations complete successfully?
- Result dimensions: How many records and fields were returned?
- Field order: Does the query return the columns that the display expects?
- Representative values: Does a known record contain the expected values before conversion?
- Missing values: Can any returned column contain a database null?
An empty result is a successful search with no matching records. A query error means the application does not have a valid new result. Give those states different messages.
Use an explicit field list in the query where practical. A display adapter tied to column positions can break if an unrestricted query starts returning an additional field or a changed field order.
Inspect a known record to establish the array orientation. If the result is transposed relative to the control, correct it at one defined boundary. Scattered transpositions make later changes difficult to trace.
Treat variants as typed values, not ready-made text
A variant carries a value and information about its type. It does not mean that every value can be converted directly into a useful display string by the same operation.
Define a small column contract before building the conversion. It should name each field, its expected native type, its null policy and its display format.
| Field purpose | Native interpretation | Display rule |
|---|---|---|
| Record identifier | Preserve the database identifier type | Display only if useful; retain the original for record mapping |
| Part code | Text | Preserve leading zeros and significant characters |
| Quantity | Integer | Show whole units without introducing decimal places |
| Measurement | Appropriate numeric type | Apply the chosen precision and label the unit |
| Recorded time | Documented date and time representation | Use a consistent format and identify the time zone when relevant |
| Optional note | Nullable text | Distinguish missing information from an intentionally empty note when needed |
Convert each variant to the expected native type before applying its display format. A numeric field should follow a numeric conversion path, not rely on an incidental text representation returned by a driver.
Do not route every number through a floating-point type merely to simplify formatting. That can lose precision for large integer identifiers or exact decimal values. Likewise, treating a part code as a number can remove meaningful leading zeros.
A failed conversion is a data or mapping problem. Do not silently replace it with an empty string and make it look like valid missing information.
Keep formatting separate from meaning
Conversion answers “What value is this?” Formatting answers “How should this value appear?” Keeping those decisions separate makes the display easier to change without disturbing calculations or record handling.
Choose formatting rules by column:
- Use consistent decimal precision for comparable measurements.
- Put units in the column heading or beside the value, consistently.
- Choose decimal and grouping separators deliberately for the application’s locale.
- Use an unambiguous date format.
- Preserve the time information supplied by the source; do not assign a time zone without a defined basis.
- Define visible labels for null, unavailable and invalid values where those states matter.
A database null, an empty string and numeric zero are different values. Whether they look different on screen depends on the task, but the conversion layer should not accidentally collapse them into one state. For example, a missing measurement must not become zero simply because zero is convenient to display.
Keep typed data available for sorting and calculations. Sorting formatted strings can place 100 before 20, and date strings do not necessarily sort chronologically. Sort the typed records first, then build the display array in that order.
Build one complete display array
Use a clear boundary between retrieval and presentation:
query result → typed records → ordered records → formatted cells → control update
A documented database helper may already return a string table. Use it only if it preserves the required filtering, field order and error handling. Confirm its behavior in the installed toolkit documentation or the manufacturer’s official documentation. A convenient return type is not a reason to broaden the query or discard important type information.
If you already have the required variant array, explicit cell conversion is often the clearer route. Traverse its rows and columns, apply the corresponding column contract, and collect the resulting strings into an array with the required shape.
Do not serialize the entire result into one string and expect the control to reconstruct the grid. Delimiters inside text fields, embedded line breaks and locale-dependent number formats make that approach fragile unless the destination explicitly requires a documented serialized format.
Prepare the complete array before updating the control. Validate the dimensions, converted cells and row mapping together. Where the UI framework supports it, publish them as one coordinated update so that visible rows and their associated records describe the same result.
Preserve row identity through sorting and refreshes
A displayed row number is a position, not a durable database identity. It can change after sorting, filtering, insertion or refresh.
Retain a stable record identifier alongside each displayed row. Build that mapping from the same ordered records used to generate the visible array. When a selection triggers another operation, resolve it through the current mapping rather than reconstructing an identifier from formatted cell text.
This matters even when the identifier is visible. Formatting may truncate it, change its presentation or omit it from a later layout. Display text should not become the application’s only record reference.
During a refresh, prevent a selection from the old result being applied to the new mapping. Depending on the application, clear the selection or restore it by matching the stable identifier after the new result is published.
For any action that changes database records, also validate that the record is still eligible for that action. Correct display mapping does not by itself establish that the underlying record has remained unchanged.
Check empty results, errors and replacement data
Check the adapter with more than one successful query. A useful acceptance set includes:
- A known record containing text, numbers and a timestamp.
- A nullable field containing a database null.
- A valid empty string and a numeric zero.
- A result with fewer rows than the previous result.
- A successful query with no matches.
- A query failure and a separate cell-conversion failure.
- A sorted result followed by a row selection.
Confirm that shorter results replace the old array rather than leaving trailing rows behind. A no-match result should clear the previous rows and state that no records matched. A failure should display an error state. If previous data remains visible, identify it as previous data rather than presenting it as the latest successful query.
For a read-only screen, include enough context to explain the values, such as units, filter scope and the time of the last successful retrieval. A successful redraw does not prove that the source data is fresh.
If the final destination is a saved image rather than an interactive table, the conversion boundary still matters. The separate guide to factory data table signage for offline screen content covers presenting that static output. Keep database retrieval, typed records and display formatting separate so each output can use the same underlying data without depending on another control’s rendered text.
Questions
Can a two-dimensional variant array go straight into a table control?
Only if the control explicitly accepts that array type. A string-based table needs a two-dimensional string array, while some data-bound controls accept typed records. Check the cell-content interface and required dimensions before converting the result. A selection value is not necessarily the interface that holds the visible cells.
Why is the table blank even though the query ran?
No matching records, a failed query and a failed conversion can all leave a table blank. Check the query error output first, then the returned dimensions and representative values. Finally, confirm that the completed array reaches the documented cell-content property rather than the control’s selection interface.
Should every database value be converted to text immediately?
Convert a value to its expected native type, then format it for display. Keep the typed records separately for numeric sorting, calculations and record actions. Turning everything into text too early can lose precision, remove leading zeros from identifiers or make sorting follow text order instead of numeric order.
How do you keep row selection tied to the correct database record?
Keep a stable record identifier alongside each displayed row and rebuild that mapping whenever the result is sorted, filtered or refreshed. Resolve selections through the mapping for the current displayed result. Do not use a row position or formatted cell text as the only reference to a database record.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.