access MS SQL/ACCESS from linux?

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.

Bingdubing@.gmail.com (dubing@.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, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||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|||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|||dubing@.gmail.com (dubing@.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, esquel@.sommarskog.se

Books Online for SQL Server SP3 at
http://www.microsoft.com/sql/techin.../2000/books.asp|||>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.