access MS SQL/ACCESS from linux?

[dubing]

Hello all,

We need to access MS SQL 2000 database from RHEL platforms. I've
tested unixODBC and Easysoft ODBC-ODBC Bridge (under trial license).
They work together pretty well. Unfortunately Easysoft ODBC-ODBC
Bridge is not a free solution. Anybody have any experiences with other
ODBC solutions that can make MS SQL accessible to unix? I've heard of
iodbc but without any hands-on details.

Thanks in advance for sharing your experience.

Bing

[Erland Sommarskog]

du****@gmail.com (du****@gmail.com) writes:

We need to access MS SQL 2000 database from RHEL platforms. I've
tested unixODBC and Easysoft ODBC-ODBC Bridge (under trial license).
They work together pretty well. Unfortunately Easysoft ODBC-ODBC
Bridge is not a free solution. Anybody have any experiences with other
ODBC solutions that can make MS SQL accessible to unix? I've heard of
iodbc but without any hands-on details.

If your budget is that slim that you cannot afford to pay for connectivity,
FreeTDS is probably your only choice. Anyway, I have a listing of all
possibilities I know of on http://www.sommarskog.se/mssqlperl/unix.html.
There is no particular indication of prices though.
--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[dubing]

Erland,

Thanks so much for the information. Man, that's a pretty comprehensive
page full of information I've been looking for. Yeah, I'm looking at
FreeTDS now.

Bing

[dubing]

Erland,

In that page you summarized various connectivity solutions, seems you
had some concerns with FreeTDS by saying:

"but personally I would be very wary of using something like this in
business-critical code".

What's the story behind that? FreeTDS is completely new to me. I'd
appreciate any suggestions or warnings so I can have something to keep
in mind while I'm look further.

Bing

[Erland Sommarskog]

du****@gmail.com (du****@gmail.com) writes:

In that page you summarized various connectivity solutions, seems you
had some concerns with FreeTDS by saying:

"but personally I would be very wary of using something like this in
business-critical code".

What's the story behind that? FreeTDS is completely new to me. I'd
appreciate any suggestions or warnings so I can have something to keep
in mind while I'm look further.

I have no experience of FreeTDS. But since FreeTDS is the reverse-
engineering of a proprietary protocol you are taking things on a dare.
There may be errors or oversights in the reverse-engineering. Most
likely such errors leads to crashes somewhere, but if things go really
bad, it results in incorrect data being read from/written to the database.

There is also the issue what happens if you open a case with Microsoft.
I have to idea what they say if you say that you connect with FreeTDS,
but it's clearly not a supported means of connection. It could be that
the issue you have run into is a bug in MS SQL Server, but since you
connect with FreeTDS, Microsoft may not look into the issue. (As they
may assume that FreeTDS is the culprit.)

--
Erland Sommarskog, SQL Server MVP, es****@sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techinf...2000/books.asp

[Bernard Peek]

There is also the issue what happens if you open a case with Microsoft.
I have to idea what they say if you say that you connect with FreeTDS,
but it's clearly not a supported means of connection. It could be that
the issue you have run into is a bug in MS SQL Server, but since you
connect with FreeTDS, Microsoft may not look into the issue. (As they
may assume that FreeTDS is the culprit.)

I was at a presentation from Microsoft recently, where they were talking
about their virtualisation products. They said that there had been a
policy change, to move towards interoperability with Linux. Whether this
policy reaches as far as their office products division I don't know.

--
Bernard Peek
London, UK. DBA, Manager, Trainer & Author.