[resolved] Cannot connect to SQL Server 2008 - Windows Athentication
Hi there. This could be simple but I cannot get it. How do you connect to SQL Server using Windows Authentication? It looks like I Profiler wants me to use SQL Server authentication only... Am I missing something? Thanks.
Greetings, I have success using SQL2008R2 on Windows 7, and the ODBC creation as you stepped through above (per usual), does work for Windows 7. However, in Talend there is no success using this ODBC/DSN or SQL Server direct for building a metadata connection. The error: Connection failure. You must change the Database Settings. Invalid string or buffer length I have tried both using SQL and Windows Authentication. ODBC connects in both cases and tests successfully, Talend is not successful. I do not have any problems connecting with SQL 2005 in Windows 7 Any other thoughts? @dledizes, have you found success?
fyi I once also struggled with sql connection and windows authentication then I found information and ended up downloading the ntlmauth.dll file and copied it to my windows/sytem32 directory which enabled windows auth from that computer. I used a normal jdbc connection from talend. Maybe this can help somebody Regards,
I'm trying to connect to MS SQL Server 2008 via the DB Connections form in Talend DQ Version 5.0.2.r78237.
I first tried selecting MS SQL Server, MS SQL Server 2005/2008 as well as ODBC in the DB type and none of these options work. ODBC connection tests correctly.
I tried both Windows and SQL Server credentials but neither functions. I tried moving the ntmauth.dll to C:\Program Files (x86)\Java\jre6\bin but that does not work.
The DB Connections functionality allows me to connect to the same DB on TOS - MDM and TOS Data Integration but not with DQ.
Any advice would be welcome.
Thanks
I'm trying to connect to MS SQL Server 2008 via the DB Connections form in Talend DQ Version 5.0.2.r78237. I first tried selecting MS SQL Server, MS SQL Server 2005/2008 as well as ODBC in the DB type and none of these options work. ODBC connection tests correctly. I tried both Windows and SQL Server credentials but neither functions. I tried moving the ntmauth.dll to C:\Program Files (x86)\Java\jre6\bin but that does not work. The DB Connections functionality allows me to connect to the same DB on TOS - MDM and TOS Data Integration but not with DQ. Any advice would be welcome. Thanks
Hi Everyone,
It is my first day on Talend and I feel as if I have been living under the 3rd rock from the sun. What an amazing product. Kudos to everyone who made this happen. I am busy with an independent review for power users and this product is right up there...
I have found a way around the SQL 2008 connectivity, but its kind of longwinded although it does work...
Firstly, there is a problem with SQL Server (ODBC) right now - TOS returns an error message that the string buffer is incorrect. Using Generic ODBC also throws an error - Invalid String or Buffer Length. With SQL Server connection, it authenticates find but if you try and import the schema it fails on authentication. The same happens on Generic JDBC.
That was the bad news.
Now for the good news...
If you download Microsoft SQL Server JDBC Driver 3.0 from their site, you could specify a generic JDBC driver. When you download the file, extract the jar via the executable.
Your JDBC URL will look something like this jdbc:sqlserver://yourinstancename:1433;databaseName=yourdbname
When specifying the generic JDBC driver ensure that you select the jar you just extracted. Click on the elipses by the class name which should populate the info for you - for in case it doesn't the class name is "com.microsoft.sqlserver.jdbc.SQLServerDriver". Enter your userid and password. Here comes the next trick --> select the Export as context button. I cannot even call myself a greenhorn on this amazing technology but I think its almost like config files. This will get TOS to remember the credentials you supplied.
TADA - when you import the schema it will be there. In my opinion generic JDBC will in any way be faster than ODBC although I wouldnt want to be quoted.
Good luck
