Using MSSQL server as a backend database for the Application running on Unix/Linux Server

 

Till few days back I was not aware of fact that there is no MS specific driver which would allow non java based application running on UNIX/LINUX platform to connect to the SQL server hosted on Windows.

And I hope that with this blog post I could help few of you folks to know what are the other available options to connect to SQL server from a UNIX/LINUX platform.

First and foremost I would like to highlight that MS has a JDBC driver which could allow Java based application running on UNIX/LINUX platform to connect to SQL server.

The SQL Server JDBC Driver is available to all SQL Server users at no additional charge, and provides access to SQL Server 2000, SQL Server 2005, and SQL Server 2008 from any Java application, application server, or Java-enabled applet. This driver is a Type 4 JDBC driver that provides database connectivity through the standard JDBC application program interfaces (APIs) available in Java Platform Enterprise Edition 5 (Java EE 5).

For more information on SQL server JDBC driver please click on the following link.

Microsoft SQL Server JDBC Driver.

Connectivity options for non java based applications running on UNIX/LINUX platform.

In a scenario where customer wants to connect to a SQL server from a PERL/C++ application running on UNIX box, there are few things to consider before the search begins for the appropriate connectivity driver.

Case 1: Interoperating an ODBC DBD Application

If the original C++/PERL application was written using ODBC DBD, then the best migration option is to continue to use this driver. Because ODBC is not database-specific, no changes should need to be made to the application's source code. The only changes that need to be made concern connectivity with the SQL Server database.

The DBD::ODBC module requires a driver manager and a driver to interact with SQL Server. DBD::ODBC is packaged with the Independent ODBC (iODBC) driver manager from OpenLink Software (https://www.openlinksw.com/). For more information about this driver, refer to https://www.freetds.org/userguide/perl.htm#DBD.ODBC. Another driver manager, unixODBC, that could be used in an interoperation scenario is available from https://www.freetds.org/userguide/prepodbc.htm.

Case 2: Interoperating an Oracle DBD Application

If the original application was written using the Oracle DBD, there are two possible options that can be evaluated. The recommended option is to replace the Oracle DBD with a Sybase DBD. The second option is to migrate to an ODBC framework similar to the one seen in "Case 1: Interoperating an ODBC DBD Application." Sybase DBD offers better performance than ODBC.

 

For more information on both Case 1 and Case 2, please click on the following link.

https://technet.microsoft.com/en-us/library/bb497071.aspx

Hope this helps,