LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

connection string (DB Tools Open Connection)

All,

 

I have been unable to pass a connection string to the "DB Tools Open Connection" function.

 

The only way I've been able to get it to work is by passing in a FILE.DSN.  This method requires the creation of a DSN using the ODBC config tool.

 

In .NET I can pass all my connection objects just a complete connection string and never touch the ODBC config tool. 

 

Has anyone been able to do this with just a connection string?  I have not seen any examples on how to do this.  It seems like LabView requires a DSN in order to access a database.

 

Thanks! 

0 Kudos
Message 1 of 8
(8,305 Views)

I have done Oracle database connections with a string.  The connection string is:

 

Provider=MSDAORA.1;User ID=userid;Data Source=datasource;Persist Security Info=False

 

Data Source is the name from the TNSNAMES.ORA files for oracle.  User ID is the user name.

Message 2 of 8
(8,301 Views)

OK looks like the missing element is "Driver=SQL Native Client"

 

This element is not listed in the Connection String website for SQL Server 2005...  Apparently Labview requires this element...

 

For future reference, the full connection string  should be:

 

Driver=SQL Native Client;server=IP.Add.re.ss;UID=userName;PW=****;Database=MyDatabase

Message 3 of 8
(8,299 Views)

dave_helmut wrote:

OK looks like the missing element is "Driver=SQL Native Client"

 

This element is not listed in the Connection String website for SQL Server 2005...  Apparently Labview requires this element...

 


This has nothing to do with LabVIEW. LabVIEW is simply calling the drivers that exist on your computer. It's those drivers that have a specific syntax requirement. 

 

I'm assuming you're referring to the site www.connectionstrings.com. In there, on the SQL Server 2005 page "Driver=SQL Native Client" is clearly shown. This is used if you're using the ODBC driver. The OLE DB driver has a different syntax. 

Message 4 of 8
(8,264 Views)

#1: I clicked your link and it took me to some strange website... not sure but forums.ni.com came up in chrome as an potentially hacked site...

 

#2: OK I went back to www.connectionstrings.com and if I scroll way down, I do see it there too.  Only reason I said "Labview needs this" is because .NET code does not need that element in there... 

0 Kudos
Message 5 of 8
(8,251 Views)
I don't have SQL Server 2005, so I can't confirm the behavior you're seeing in .NET. Are you sure you're using the same driver in .NET as you are in LabVIEW? Again, the connection string depends on the driver that you're using.
0 Kudos
Message 6 of 8
(8,243 Views)
I suspect they use the same driver (installed on the OS), and the .NET environment is just more forgiving.
0 Kudos
Message 7 of 8
(8,239 Views)

dave_helmut wrote:
I suspect they use the same driver (installed on the OS), and the .NET environment is just more forgiving.

That would not be a correct assumption. You typically specify which driver to use. In .NET I believe the default is to use the .NET Framework Data Provider, and the connectionstrings.com page shows that with that you can use the alternative syntax which looks like this:

Standard Security alternative syntax
This connection string produce the same result as the previous one. The reason to include it is to point out that some connection string keywords have many equivalents.
Server=myServerAddress;Database=myDataBase;User ID=myUsername;Password=myPassword;Trusted_Connection=False;
 
LabVIEW would (obviously) not use the same driver.  By specifying Driver="{SQL Native Client}" you are indicating to use the Native Client ODBC Driver.
0 Kudos
Message 8 of 8
(8,235 Views)