TestStand Database

[CC57]

How do we create a new instance of a database for each UUT run.  We are collecting the data for each run correctly but don't want it in one database.  We are using TestStand 2013, and Access.

[~jiggawax~]

Why would you not just create an XML report for each or an ATML report for each if you want a different file for each UUT?

In the Database Options callback you could copy a template mdb file to the UUT specific named file.  Then change the Parameters.DatabaseOptions.ConnectionString to point to the copied file.

Just an idea.

[Dennis_Knutson]

Seems to defeat the purpose of using a database at all, though Access/Jet is hardly a great choice In the first place.

[Scott_Richardson]

In order to force the logging component to reconnect to the database, and for the TestStand process to unlock the file, it must release its connection to the Access database. After this is done, you can do what you will with the access database file before the next UUT starts and logs. The database logging feature attaches its connection reference with the database to the execution object under the name "TSDatabaseLoggingDatalink*" where "*" is a unique suffix. You might have to set the station option to view hidden properties to see this on the RunState.Execution object in the variables view after logging the first UUT.

[mwatkins]

---

@Scott_Richardson

Hi Scott, 

I am trying to get this to work. In my scenario we need to call a external process that will connect to local database on test station and extract some data. This requires the local Access database connection to be closed. I have tried your suggestion (see screenshot below). 

Should I expect to see the .laccdb file disappear after this step runs? Any timing that needs to be observed?   Of course I'm asking because simply calling the statement as shown does not close the Access database connection. 

Force 'TSDatabaseLoggingDatalink*" to False

[Scott_Richardson]

I have not worked with Access in quite a while. I do remember that the deletion of the .laccdb file was an indication of the closing of the connection, but I do not know what else might come into play. I do not know of any way to truly determine when the database no longer has a process with write access, other than retry. This is a limitation of Access database. My only recommendation would be to see if you can move to a local SQL Server database instead, which has options for multiple writers and readers.