Writing data to Microsoft SQL Server/Dat​abase

Question

Hi All
I have written a program in LV ver 6.1 that carries out various functional tests and at each test gathers 3 data values. At the moment the data is gathered at each stage of the test and written in a concatenated string to a file that was opened at the start of the test routine. What I need to do is output the data such that it is compatable with SQL server (presumably in some form of table?). I have read previous posts but they recommed the ni database toolkit, which I do not have. Should I be using the XML vi to take the string of data or use the active x vi? I have read in other posts that you can manage without the ni database toolkit but would need to program a database structure. My knowledge of database development is nil and I wondered if there was a vi that could be used that would create tables that could be directly interpreted by MS SQL?
Labview Version 8.5
Labview Version 8.6
Labview Version 2013

Answer 1

I'm having trouble understanding exactly what you're doing, but I will try to explain a few things:
Ideally code written for database connectivity should not be included in my Labview code or problems could occur if my client changed his servers , database structure etc.
The code can be yours. If you do write it, just make sure to create subVIs, so that if the DB structure does change (something which is rare), you will only need to change the code inside the subVIs.
Microsoft SQL server is an intermediate piece of software that allows my Labview code to access the database without actually 'seeing' it. With my client using SQL server they can modify the way my Labview code sends data to their database if they decide to change their servers, database structure etc.
SQL Server is the DB management system. It holds all the tables, queries, etc. and is responsible for actually managing the DB itself.
What Dennis suggested was that the DB guy will write something known as a "stored procedure" and that you will call it.
In such a case, if the DB guy wanted to change something, he could just change the stored procedure and (if the change does not affect the interface), you do not have to change or rebuild your program. This is equivalent to the subVIs I described earlier, except in this case, the function is inside the DB itself.
Another version of this is creating a table with SQL commands and assigning a name for each command. You load the SQL command from the table by name and execute it. This allows for changing the SQL command inside the DB without changing your application.
ADO connectivity is used and the connection string is best located in the windows registry file. Presumably this option would give my client the most flexiblity? Is this the same thing as the .udl file?
Basically, the scheme is like this:
DB <-> DBMS <-> ODBC <-> ADO <-> Your Application
This may not be perfectly accurate, but the concept is basically this - in Windows, you talk to ANY database from ANY program using the same interface - you call ADO functions which will be responsible for getting to the DB you want and you use SQL to issue the commands, since the basic SQL commands are supported by all DBs.
To identify the DB, you use a connection string. This connection string can have all the data in it or it can point to an existing file (UDL or DSN) which holds the data pointing to the DB. Dennis suggested that when developing on your machine, you will use a file pointing to a local DB, but when deploying you will use a file of the same name which will point to the real DB. Your program will always go to the file and from there it will know which DB to go to.
The only time when this should really matter to the client is during configuration (for example, if the DB was moved to a different machine). All the client needs to do is edit the UDL file to point at the new location of the DB.
Again, the advantage of all this is that this is not part of your code and is done by programs which are built to handle it.
It is more efficient to use the Parameterized database technique such as the example given in the 'logging example parameterized'
I don't know how much this efficiency will be relevant in the speeds you need.
In any case, as I said, my own preference is to create functional subVIs - for example, a VI which will accept data in my format and will be responsible internally for converting that data and putting it into the necessary tables.
I have sent my client an outline of the data to be saved on their database, which at the moment comprises of 3 tables, the first has things like operators name, date, time, serial number etc ( 7 records, 3 fields) the second table has test reference (11 tests in total) with items such as fuel flow, fuel temp etc (11 records, 5 fields), Last table has 1 record and 6 fields. Unlike the Labview example each stage of the test can take up to 4 minutes to complete and if successfull the program moves on to the next stage of the test, saving the test results and if a PASS or FAIL occurred. The question I have is would it more efficient to save the results at the end of all of the tests or shold I connect to their database and save results as the tests progress?
I can't say I understand this, but my suggestion would be to let the client decide in what format they want the data, since they're the ones who want it. Work with the DB guy to decide exactly what data you need to put into the DB and where and then you can decide exactly which functions you need. As said, you might want to let the DB guy write some stored procedures which you can use to input the data.
Unless it's a large amount of data, writing to a DB is usually fairly quick (under a second). If it is relevant, my suggestion would be to write after each phase.
In any case, I suggest you go through some real DB tutorials (not LV related) and see if you can wrap your head about it. I know I don't particularly like designing DBs (or PID) any more than you do, but it's a skill worth having, and in some places, a DB makes things easy and practical.
Try to take over the world!