Retrieving NI TestStand Double Arrays from SQL Server

NI Database Viewer displays the stored double array, but a web application receives a database field rather than individual numeric elements. SQL can retrieve the field from PROP_BINARY; whether SQL can expose the array as relational values depends on the field's SQL data type and the serialization format used when TestStand wrote it.

Initial retrieval decision

1. Run a normal SELECT against PROP_BINARY for one known result row. Confirm that the query returns a non-null value before attempting to decode it.
2. Read the selected column's SQL data type. If it is a numeric SQL type, retrieve it normally through the application's database driver. If it is a binary type, treat the result as a byte sequence rather than as a SQL array.
3. Compare the same row in NI Database Viewer. Do not move on until the SQL result and viewer entry refer to the same TestStand result record.

The database was created by SQL Server Create Generic Recordset Result Tables.sql on Microsoft SQL Server 2008. That establishes a generic TestStand result schema, but it does not establish the binary column name, its serialization layout, or the row-key relationship for this installation. Read those details from the deployed database rather than hard-coding assumptions.

SQL storage-type check

Before anything else, inspect the catalog instead of inferring the field type from the table name. SQL Server 2008 exposes the declared type and maximum length through its system catalog:

If returns no match, qualify PROP_BINARY with the schema name used by the deployed database and rerun the inspection. Record the actual payload column, key columns, and nullable status. Do not move on until the web application's database account can see the same object.

A binary field can be selected by ordinary SQL, but SQL Server does not automatically know that its bytes represent a TestStand array of doubles. A successful SELECT proves access to the payload; it does not prove that casting the payload to a SQL numeric type will reproduce the array.

Row identity and raw-value retrieval

Use one known array as a controlled sample. Select the row by the actual key columns discovered in the schema, not by array contents or display text:

SELECT [binary_column]
FROM [schema_name].[PROP_BINARY]
WHERE [key_column] = @key_value;

The bracketed names are placeholders for the identifiers read from the database. Use a parameter for @key_value. Confirm all three observations before decoding:

1. The query returns exactly the intended record.
2. The payload is not NULL and has a nonzero byte length.
3. The NI Database Viewer shows the expected double array for that same record.

If the query returns multiple rows, resolve the missing key relationship first. If the viewer shows an array but the selected row is empty, the viewer is probably following a related result or property record that the web query has not selected. Inspect the deployed schema's keys and joins; do not guess column relationships.

Binary-payload interpretation

The decisive branch is the payload representation. Read the retrieved field through the database driver using its binary or byte-buffer API. Then determine how TestStand encoded the array. The byte order, element boundaries, any length prefix, and any type header must match the writer. Casting an entire serialized array to a SQL floating-point value cannot split it into elements and may discard structural bytes.

NI Database Viewer can display the values because it understands the TestStand result schema and stored representation. A general web stack normally sees only the SQL field. If the serialization contract is not available, use TestStand Database Step Types or another TestStand-aware component to read the record and export a documented application format. This keeps TestStand-specific decoding out of the web tier.

Web-application retrieval procedure

1. Open a read-only database connection using an account that can select the required TestStand result tables. Confirm access with a query limited to one known record.
2. Read the catalog metadata for PROP_BINARY. Record the schema-qualified table name, payload column type, key columns, and related-table keys.
3. Issue a parameterized query for the controlled sample. Confirm the returned row maps to the same result displayed in NI Database Viewer.
4. If the driver reports a binary field, retrieve it as bytes without text conversion. Confirm the byte count remains unchanged between SQL Server and the application buffer.
5. Decode the buffer only after identifying the exact writer format. Apply its header, count, byte-order, and element rules as defined by that format; do not infer them from one sample.
6. Return the decoded values to the web layer as an explicit numeric array. Preserve array order and reject payloads that fail the format's structural checks.

If TestStand itself must perform the query, use the TestStand Database Step Types. For a separate web application, the normal SQL query path is sufficient for retrieving the database field, while decoding remains an application-format responsibility.

Verification and recurring pitfalls

Validate with more than one stored array, including arrays with different lengths and values. Compare the element count, order, and each decoded value against NI Database Viewer. A decoder that works for only one payload may have mistaken header bytes for data or relied on a fixed length.

FAQ