Jump to content
Chris

Automatically install Database System DSN Link

Recommended Posts

Hi all,

Uptil now whenever I've installed a LabVIEW application onto a client's computer that uses MySQL Server, I have had to manually configure a System DSN entry so that the NI Database Connectivity Toolkit VI's can access my database. Is there a way that this can be included/configured in the LabVIEW Installer so the installation is fully automatic - in fact is it possible to do a complete installation of the MySQL Server, ODBC driver and System DSN (or UDL file) directly from the installer without any user input required?

Thanks for help Chris.

Share this post


Link to post
Share on other sites

Hi, Chris

I don't have a complete answer for you because it's been a while since I've had to build an installer like you mention. You didn't say what version of LabVIEW you use; my suggestions refer to the Installer Build Specifications found in LV 8.x projects:

- System DNSes are registry entries. So you can figure out their various keys and have either the installer create them or you could write a short LV program or batch file that creates them and runs after the main installer. There is a Registry category in the Installer Properties.

- In the Advanced category in the Installer Properties you can specify EXEs to run after the main installation. I've used this to install non-NI drivers, run batch files, etc. You could use this to install MySQL components. You can also enter command line arguments here.

Edited by xtal

Share this post


Link to post
Share on other sites

I have avoided Data Source Names in ODBC all together by connecting directly to the database server using a connection string like this:

Server=yourdatabaseserver.domain.network.com;Database=yourdatabase;User ID=youruser;Connection Timeout=60;Trusted_Connection=FALSE;Net=dbmssocn;

I use and ini file to specify the components of that connection string so the customer can edit them as needed. you could have your app pop up a dialog on first run to query the customer for those values and write them to the ini file.

I am using the ADO.NET interface to talk to SQL server, by MySQL should also be supported.

Share this post


Link to post
Share on other sites

Thanks for these ideas. We have finally upgraded to LabVIEW 2009 so hopefully the Installer will be a lot easier and more flexible to use.

I think I prefer John's idea, simply because I don't have to mess around with the registry, which is always a danger.

However I am actually using the NI Connectivity Toolkit (NI-CT) and I always assumed you had to create a DSN through the ODBC driver so I could interface to the Database (either that or use the UDL file technique). Is it because you are using the ADO.NET interface you don't have to use this?

I saw some tests that said the NI-IT was faster than ADO.NET as returned data queries grew larger (say a 1000 rows). Although ADO.NET doesn't use the extra ODBC layer I thought it was still slower?

So my question is if I was to interface to say a MySQL database on the same machine as my LabVIEW application through the NI-CT can I just create the following ini file:

Server=localhost;Database=imt;User ID=root;Connection Timeout=60;Trusted_Connection=FALSE;Net=dbmssocn;

and I could just pass these values into the DB Tools Open Connection.vi and it would link to the database?

I presume if there was a password then Trusted_Connection=TRUE and we would have to put a password entry (Password ID=blabla)?

Also what does Net=dbmssocn mean?

Thanks Chris.

Share this post


Link to post
Share on other sites

I've used connectionstrings.com once or twice to resolve problems connecting to databases. :thumbup1:

There are sections for most of the major DBs as well as using Excel files!

'dbmssocn'

The network library used to establish a connection to an instance of SQL Server. Supported values include dbnmpntw (Named Pipes), dbmsrpcn (Multiprotocol, Windows RPC), dbmsadsn (Apple Talk), dbmsgnet (VIA), dbmslpcn (Shared Memory, local machine only) and dbmsspxn (IPX/SPX), dbmssocn (TCP/IP) and Dbmsvinn (Banyan Vines).

The corresponding network DLL must be installed on the system to which you connect. If you do not specify a network and you use a local server (for example, "." or "(local)"), shared memory is used.

  • Like 1

Share this post


Link to post
Share on other sites

I don't use the NI-CT toolkit because it is way too slow for large record sets. I 'rolled my own' database toolkit by calling ADO.NET directly from LabVIEW. To get large record sets, I use the tricks from Brian Tyler's old blog on how to move large data between .NET and LabVIEW using arraylist data types. I did need to write a very small c# function to do this but it was not too hard.

If you are not up for that yourself, I think the NI-CT does have a way to establish a connection using a connection string. As I said above, I saved the variables in an INI file and then read them in and use a format into string to construct the connection string on the fly and open my connection.

I believe you will still need the MySQL driver installed on your system, but should be able to avoid the process of setting up an ODBC link with the data sources manager tool. I used to do that back in the Win3.11 days and it was a PITA.

good luck!

-John

Share this post


Link to post
Share on other sites

So my question is if I was to interface to say a MySQL database on the same machine as my LabVIEW application through the NI-CT can I just create the following ini file:

Server=localhost;Database=imt;User ID=root;Connection Timeout=60;Trusted_Connection=FALSE;Net=dbmssocn;

and I could just pass these values into the DB Tools Open Connection.vi and it would link to the database?

Yes, you just wire the string directly to the Connection Information input on the Open Connection VI.

Share this post


Link to post
Share on other sites

Firstly I tried connecting to my MySQL Database (on my local machine) called 'imt' through a System DSN that I manually created and of course it worked.

I then deleted the System DSN entry and tried connecting to the 'imt' database using the connection information suggested by John (see No System DSN.jpg image) with a little bit added for the password and it just came up with the error "Data source name not found". I also tried Net=dbmslpcn and no entry for the Net variable.

Could someone explain to me what I've done wrong - I'm sure it's something really simple.

post-317-127099438699_thumb.jpg

post-317-127099515015_thumb.jpg

  • Like 1

Share this post


Link to post
Share on other sites

Firstly I tried connecting to my MySQL Database (on my local machine) called 'imt' through a System DSN that I manually created and of course it worked.

I then deleted the System DSN entry and tried connecting to the 'imt' database using the connection information suggested by John (see No System DSN.jpg image) with a little bit added for the password and it just came up with the error "Data source name not found". I also tried Net=dbmslpcn and no entry for the Net variable.

Could someone explain to me what I've done wrong - I'm sure it's something really simple.

Bascially what you should do to get the right direct connection string is to configure a database with the Windows ODBC Configuration and then go and look in the registry what that results into.

"HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\ODBC Data Sources" lists the installed user DSNs, while

"HKEY_LOCAL_MACHINE\Software\ODBC\ODBC.INI\ODBC Data Sources" lists the installed system DSNs.

Under the "HKEY_<user or system>\Software\ODBC\ODBC.INI\<DSN name> you will see a list if keynames and values that you want to put into your direct connection string, separated by semicolons, to get the same effect as when you would specify an according configured DSN name.

Share this post


Link to post
Share on other sites

Thanks for that Rolf. You would think that with such a straightforward explanation it should be easy to get working, but alas I've let you down sad.gif

I found the registry settings OK and tried a couple of different connection strings (see attachment) based on the keys, but none of them worked.

Are the Key Names case sensitive or does the order in which you put the Key names important? Do I have to include the Driver Key Value?

post-317-127123978554_thumb.jpg

Share this post


Link to post
Share on other sites

It's OK I figured it out, by looking at the latest post from Pravin

http://lavag.org/topic/12237-how-to-connect-sql-server-2008-to-labview/

There was a reference to all the different types of connection strings to databases and I came across one for the ODBC Driver 3.51 that we used:

Driver={MySQL ODBC 3.51 Driver};Server=localhost;Database=myDataBase; User=myUsername;Password=myPassword;Option=3;

so even though my registry entry said the Driver Key value was C:\WINDOWS\System32\myodbc.dll if I used {MySQL ODBC 3.51 Driver} instead it worked.

Thanks for everyone's help.

Share this post


Link to post
Share on other sites

so even though my registry entry said the Driver Key value was C:\WINDOWS\System32\myodbc.dll if I used {MySQL ODBC 3.51 Driver} instead it worked.

Sorry for that! It has been some time that I had to play with that. The {MySQL ODBC 3.51 Driver} is in fact an alias to another section in the registry that eventually points the ODBC manager to the original DLL as you have tried it out first. I was under the assumption that a direct driver path should work too, but have to admit that I can't say for sure. Maybe it is also a Windows version thingie too.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.