Robert Denton wrote: > Okay, as it tunrs out maybe it is not all that difficult > afterall... With the help from someone form the FreeTDS developers > team I got it to work. All I had to do was the following: > I'm happy you are up and running. > ~~~~~~ > >> Since I just got this set up for myself... >> >> odbc.ini: >> >> [ODBC Data Sources] >> TEST = Microsoft SQL Server 2000 >> >> [TEST] >> Driver = /usr/lib/libtdsodbc.so >> Description = TEST Data >> Trace = No >> Server = 192.168.100.250 >> Database = TEST >> ;Port = 4444 >> TDS_Version = 8.0 >> In fairness to anyone else that might read this and copy it, it is not actually correct if you are using unixODBC which does not have an "ODBC Data Sources" section at all. Now I am wondering if you were really using unixODBC or in fact iODBC or some other driver manager. Your principle problem was neglecting to specify dbi:ODBC in the DBI connection string (which you concede below) and it was compounded by using driver= instead of DRIVER= in the ODBC part of the connection string. Had you corrected these, I'm sure you would have connected ok as freeTDS knows about unixODBC and happily works with it. >> ---------------- >> >> /etc/freetds.conf >> >> [SERVER] >> host = 192.168.100.250 # server.test.local >> port = 1433 >> tds version = 8.0 >> >> ----------------- >> >> #!/usr/local/bin/perl >> # >> use DBI; >> >> my $dbh = DBI->connect("dbi:ODBC:TEST", 'DOMAIN\user', 'domainpwd', >> {PrintError => 1, RaiseError => 1, LongTruncOk=>1}); >> >> die "Unable for connect to server $DBI::errstr" >> unless $dbh; > > In actual fact if you read the FAQs mentioned in a previous posting on this thread you will see that although the above works, 'dbi:ODBC:DSN=TEST' is better - see http://www.easysoft.com/support/kb/kb00097.html for why. > ~~~~~ > > My biggest error, other than borrowing unproven connect() syntax from > who-knows-what-google-return, was in not declaring "dbi:ODBC:" in > from of the data source and also in not defining my odbc.ini file. > Many thanks to everyone who contributed to the resolution of this issue > > Robert > > <snipped old context> Interestingly, an age old issue arises out of your post which is what the ODBC specification says you should report as an error for certain situations e.g. DSN not found and no DEFAULT found.... In reality, on UNIX no one writes a default section in their odbc.ini file so the misdirection to a DEFAULT driver nearly always confuses. The reality is when you specified driver={xxx} the driver manager could not find a DSN= or a DRIVER= so it errored with the less than helpful error that ODBC says it should. I will pass this on to Nick (@unixODBC) to see if he can be persuaded to deviate from the the spec and provide a slightly more useful message (as Tim has done to a different degree in DBI). MartinThread Previous | Thread Next