LabVIEW Database Connectivity Toolkit and SQL Schema Synchronization

Short answer

Yes to both, with one clarification. The Database Connectivity Toolkit does not bind result sets to your clusters — your application does, at the Variant To Data call. The reliable validation layer therefore stops converting whole result sets in one step: fetch rows as the toolkit's default 2D array of variants, diff the result-set metadata against a stored schema descriptor, and convert column by column. Because type binding lives in your conversion code rather than in the toolkit, mappings can be rebuilt per query at runtime; the connection refnum is the only long-lived state.

Confirmed behavior versus version-dependent behavior

Assumption: NI's ADO-based Database Connectivity Toolkit on Windows with a recent LabVIEW release. The split below separates well-established behavior from what must be tested on your target version.

Also verify support status: the toolkit is a legacy, ADO/Windows-bound product, so confirm compatibility with your LabVIEW release before building a long-term layer on it.

The minimal validation layer for this case

1. Snapshot the expected schema at development time into a versioned descriptor: column name, ordinal, and target LabVIEW type per field — or a typedef'd cluster plus a parallel descriptor file.
2. Diff actual against expected after each query. For SELECT projections, prefer database-side metadata (INFORMATION_SCHEMA.COLUMNS or your server's equivalent) over DB Tools List Columns, because the latter describes table schema, not the query's output columns. Normalize raw provider type codes (ODBC and OLE DB differ) into categories: integer, float, string, datetime.
3. Fail explicitly on mismatch: log expected-versus-actual and refuse to run, or route to a compatibility mapping. This converts silent truncation — a widened numeric coerced into a narrower LabVIEW type, for example — into a logged failure.
4. Convert by name, not by ordinal. Avoid SELECT * and hard-coded column order; that is the root cause of the mismatch. Select columns by name from the variant rows, convert each with Variant To Data inside a subVI with an error cluster, and assemble the cluster with Bundle By Name.
5. Add a schema-version gate when the connection opens — a version row or metadata query — so the application fails fast instead of at the first query.

Because mapping is rebuilt per query from the descriptor, runtime reconfiguration is just loading a new descriptor file or service response. What genuinely requires redeployment is changing a strict typedef's element layout; if the cluster shape itself must evolve, decouple with name/value pair arrays or LabVIEW classes with dynamic dispatch instead of rigid typedefs.

One detail that changes the recommendation

Confirm the connectivity path. Everything above assumes NI's ADO-based Database Connectivity Toolkit. If the application actually uses .NET interop (ADO.NET) or a raw ODBC library, the metadata VIs and variant behavior differ, and the validation layer must target that API's metadata objects instead. Which of the three paths is in use determines whether the toolkit's metadata VIs are available at all.

Verification steps

• Open the Database Connectivity Toolkit palettes in your LabVIEW install and confirm the metadata VIs and the variant output of the fetch VI.
• Create a two-column test table, add a column, alter a type, and confirm the validation subVI reports the diff instead of crashing.
• Check NI documentation and release notes for your LabVIEW version on Variant To Data coercion rules and toolkit compatibility, and query INFORMATION_SCHEMA.COLUMNS on the target database to confirm the diff fields exist.