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).
Martin
