Accessing from linux

Hi All,
Can I connect to the MS SQL database from the Redhat Linux 9.
Is there MS SQL client or database driver on linux available. I wanted to use the data from the MS SQL database in the C++ program running on Linux.
Thanks in advance,
torpedoYou can use ODBC driver. Just find and download the correct one.
I had quick serch on google and found this:

http://www.datadirect.com/download/index.ssp|||On Linux, you probably want Free TDS (http://www.freetds.org/).

-PatP

accessing a remote Windows database

I'm trying to figure out how to access a Windows database (SQL server) from a Linux server. I'm trying to use Win32::ODBC and I've got a lot of information on how to make a connection, running queries, extracting the data, but the piece that I'm missing is what do you do if your database in NOT local ?? I'm assuming accessing remote databases is something developers do, so I'm a little confused on why I can't find any data about this. Can you provide any information ?In the strictly ADO microsoft world, you can supply a Data Source parameter on your connection string. The data source would be the name or IP (hopeflully name) of the server the database lives on.

Also, you may have better luck in trying to get the DBI's/DBM's for perl and SQL Server.|||I'm not very familar with the windows world (I'm in the Linux/Unix) ... can you possibly give some examples/references of what you mean ? Basically, someplace where I can see some sample code

Thanks !!|||If you have a connection string that you are passing to the connection object, it would look like this in Windows:

"DSN=SomeDSNName;UID=UserName;Password=Something"

The ODBC DSN (Data Source Name) will direct the request to the correct driver, server, and in some cases the database as well. If you do not have a DSN available, you have to supply these yourself:

"Provider=SQLOLEDB;UID=UserName;Password=something; Data Source=ServerName;Database=DatabaseName"

As for examples from a UNIX/Linux world, I am at a total loss. I was not even sure that ODBC existed on Linux. Hope this helps.|||I think I need to use the DBI::Proxy, I just have to make sure the correct modules are loaded on the windows machine

How do I access a MS Windows based database from UNIX/Linux using DBI::Proxy?
On the UNIX/Linux machine install DBI and all the modules to support DBD::Proxy.
On the Windows system install DBI, all the modules for DBD::Proxy, and DBD::ODBC.
Define a system DSN (using ODBC connection manager) to the Windows database.
Using the ODBC Test connection, test the ODBC connection.

I just know much about loading modules on Windows. Any thoughts on that ??

Thanks for your help so far.

Access SQL Server 2005 from C++ programs in UNIX/LINUX

Hi,

Is there as way to access SQL SErver DB for DML Operations from C++ programs in UNIX/LINUX. The current approach is by uisng Pro C to connect to ORACLE from C++. But I want to connect to SQL Server 2005.

Regards,

Kart

The best approach here is to convert the application to use ODBC rather than Embedded SQL and access SQL Server via one of the 3rd party ODBC drivers for SQL Server, such as Data Direct ( http://www.datadirect.com/products/odbc/index.ssp )

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.