NI TestStand

cancel
Showing results for 
Search instead for 
Did you mean: 

Proper use of database steps.

Hi all,

 

I'm working on a project where i'll be logging information to an Access database (.mdb). I am trying to determine the proper procedure for opening and closing the files. I apologize for my lack of knowledge on the subject, databases are a new thing to me!

 

In the past I have always wrote to text files, when I needed to write, I would open the file, write and then close immediately. Would this also be the correct approach with a database file? Or should I open my connection to the database on test start and keep it open during the entirety of the test?

 

 

I need to log to the database during the test, and these tests are extremely long, possibly 3-4 months long. I want to make sure that the database can be accessed by Access if possible during the test.

 

Thanks!

 

0 Kudos
Message 1 of 10
(4,346 Views)
I would recommend that you use the process model for logging and let it handle the details. Select on-the-fly so the results get stored as the test runs. I would also recommend you use a real database instead of access. There is MySQL and the free version of SQLServer.
0 Kudos
Message 2 of 10
(4,343 Views)

Thanks for the quick reply!

 

I assume to use the process model I will need to create  a custom schema in the Database Options dialog? Also, any issues doing this with the parallel process model?

 

I am locked into Access by the customer, wont be able to change that unfortunately.

0 Kudos
Message 3 of 10
(4,325 Views)
Before you do any work for a customer, you need to take a few TestStand classes. These are basic questions. Yes, you need to use a schema and the default one is the one you should start with.

The jet database will give problems if you need to read it while writing. Your customer doesn't sound very knowledgeable either.
0 Kudos
Message 4 of 10
(4,319 Views)

Well... Thanks for the berating...

 

I have taken both TS courses, it was some time ago and I have not used any database functionality. Some concepts tend to fade when not used.

 

Apparently expecting help from a support forum is a lot to ask for...

0 Kudos
Message 5 of 10
(4,312 Views)
My intent was not to berate you. The database functions are pretty basic to TestStand and one of its most valuable features. Your question seemed like it was coming from someone who had never taken any of the classes. I have helped you in telling you that the jet database is not very robust and you will likely have problems. This is coming from someone who had been a TestStand user since version 1.0.
0 Kudos
Message 6 of 10
(4,306 Views)

Are you using the Access database for the results from the test or is it going to be used for other data?

 

My thoughts are: if you use it for the results, no need to modify anything.  Just turn it on and away you go.  Unless they have specific requirements for the tables.  In that case you would need to create your own plugin or schema.  That can be a bit tricky.

 

If you are using it for other data I would use a code module to do the database communication.  I find the TestStand steps are a bit tough to use.  I do think that you can call directly into .net assemblies or activex steps to talk to access through it's API.  That would be harder though.

 

Regards,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
0 Kudos
Message 7 of 10
(4,279 Views)

Hi Jiggawax,

 

It will be used for test results and some other data as well. They do have specific requirements for the table, I have tried going in and developing my own schema and I agree that it is quite tricky.

 

When you mentione code modules, do you have any recomendations other than the TS steps or calling the ActiveX steps?

 

Also, going back to the original question, if I do use code modules, should I leave the connection open? Or should it be opened and closed as needed?

 

Thanks!

 

 

0 Kudos
Message 8 of 10
(4,251 Views)

If it is results then I recommend using changing the schema.  You would have a lot to learn to come up to speed on that as Dennis suggested. 

 

Here is a tutorial for modifying the schema:

http://www.ni.com/tutorial/6484/en/

 

For the other data I would just do it in a LabVIEW step.  Probably open and close within LabVIEW if it wasn't too processor intensive.  You can pass the handle in and out but that's just a pain unless you need to write a lot of data quickly.  OR instead you can just make the other data a result and handle it in your schema.  That way you only have one thing doing the database talking.  Plus the nice thing about the schema is that it will run in the Plugin which runs asynchronously to your execution.  This allows you to collect data faster.

 

Hope this helps,

jigg
CTA, CLA
testeract.com
~Will work for kudos and/or BBQ~
Message 9 of 10
(4,248 Views)

Couple additional things to consider with hard requirement to use MS Access:

 

  1. I beleive that the 2013 ms access DB size limit is 2gb.  If you are going to be logging for 3-4 months non-stop make sure that you caculate how much data you will need to store during this period and that if fits within the limit of the DB,
  2. Since you will be logging for so long i recomend that the DB be as close to the test system as possible network wise, possible even running on the same machine.  Since you will be using "on the fly" any loss of connection to the DB will cause an error that will interupt and most likely stop your testing.

Cheers

Herrlin

Just trying to spread the LabVIEW love.
Message 10 of 10
(4,166 Views)