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!
It may be more work for him but that's what he is there for and it sounds like it's his company that wants the test data integrated into the database. You could probably leave a lot of the details up to him and let him decide on the basic design. He will need to contact the users and find out how they wish to use the data. For example, your test results may need to link to shipping. Besides the test results, you might also need to store the serial number. The date/time of the test is usually a requirement as well. The IS person is (or should be) capable of writing a stored procedure that makes it a bit easier for you as well. A stored procedure is basically a program that will accept parameters and do all of the low level database commands for you. 