Problem Boundary
A VC++ DLL opens and reads a Microsoft Access database when called outside NI TestStand, but cannot open the same database when TestStand calls it. The evidence does not identify the database-access method, failing function, exception, or TestStand configuration, so it does not support a single confirmed root cause.
| Confirmed | Unknown to capture |
|---|---|
| The DLL was created with VC++. | Whether it uses ActiveX, ADO, DAO, or ODBC. |
| It works outside TestStand. | The OI used for the successful call. |
| The Access file does not open from TestStand. | The exact error or exception and failing function call. |
Capture the Actual Database Failure
Instrument the DLL to report the exact error or exception at the database-open operation. If the implementation uses ADO or DAO, identify the precise ADO or DAO function call that fails. This separates a database API failure from a DLL-loading problem and provides a repeatable comparison between the working OI and TestStand.
- Identify whether the DLL accesses the database through ActiveX, ADO, DAO, or ODBC.
- Run the DLL through the working OI and record the result at the database-open call.
- Run the same operation through TestStand and capture the exact error or exception at the same call.
- Compare the two call paths before changing the DLL or TestStand configuration.
Check DLL Dependencies
Run Depends.exe against the VC++ DLL and inspect whether a required library is unavailable when TestStand loads it. A missing dependency is a supported diagnostic hypothesis, not a confirmed cause: the working compiler-hosted execution may load a library that is not loaded in the TestStand execution context.
Verify the result by correcting any identified dependency-loading problem, restarting the TestStand call path, and repeating the same database-open operation. If Depends.exe shows no missing dependency, return to the captured database error and failing ActiveX, ADO, DAO, or ODBC operation rather than assuming a loader fault.
Verification Criteria
Consider the issue resolved only when TestStand calls the DLL, the DLL opens the same Microsoft Access file, and the read operation completes through the previously failing path. Retain error reporting around the open call so a recurrence exposes the failing API operation instead of only reporting that the file could not open.
FAQ
Why does my Access DLL work outside TestStand but fail inside TestStand?
The evidence supports two diagnostic paths: capture the exact database API error and inspect the DLL with Depends.exe for a dependency that is unavailable in the TestStand context.
What should I log when a VC++ DLL cannot open Access from TestStand?
Log the exact error or exception, the failing function call, and whether the DLL uses ActiveX, ADO, DAO, or ODBC. Compare those results with the successful OI call.
How do I check a TestStand DLL for missing dependencies?
Open the DLL in Depends.exe and inspect its required libraries. Treat any missing library as a hypothesis, correct its loading problem, and repeat the database-open call in TestStand to verify the result.
