ODBC connection from 64-bit SQL Server to Informix data source

Question

I am trying to create a linked table in a 64-bit SQL Server to Informix, and the SQL server does not list Informix ODBC in the DSN list. I have downloaded the 64-bit Informix Client SDK, however, despite the fact that it states 64-bit Informix Client SDK, it only appears in the 32-bit ODBC DSN. I tried to create a linked table in a 32-bit SQL Server and I was then able to see Informix ODBC DDN.

I was just wondering that if there is an Informix Client SDK that would show in the 64-ODBC DSN, not the 32-bit?

Also is there a way of linking a 64-bit SQL Server to Informix please? Thanks.

Answer 1

Create a DB Link in SQL Server to Informix

I used the following Software environment:

• SQL Server 2012
• Informix SDK 4.10 FC2
• Informix 11.5

First Set some Properties for Ifxoledbc Driver:

Then Create Linked Server:

General Settings - Datasource is your DB and your Server Name

Security Settings - Add valid Informix Database Credentials

Server Options - Set RPC and RPC Out to True

I use the db link for calling a stored Procedure in Informix and writing the data to SQL Server.

Answer 2

I was able to set up a linked server without Ifxoledbc. Once my System DSN for the 64-bit ODBC driver was set up (and tested OK), I set up a linked server using the Microsoft OLE DB Provider for ODBC Drivers.

Linked Server: UCCX
Provider: Microsoft OLE DB Provider for ODBC Drivers
Product name: IBM Informix ODBC Driver (probably could be anything but I named it the same as the ODBC Driver and it worked).
Data Source: UCCX (the name of your System DSN).

On the security tab I mapped a local login to the same remote user/password as the one set up in the System DSN itself.

And another way to consume the System DSN is via OPENROWSET. This works even without setting up a linked server:

select *
from    openrowset('MSDASQL', 'DSN=UCCX', '
            select * from ContactCallDetail
            where   StartDateTime >= ''2017-03-10 00:00:00''
            and     StartDateTime < ''2017-04-10 00:00:00''
            limit 10'
        ) p

Answer 3

Did you use the 64 bit version of ODBCAD32.EXE to create the DSN?

There are two versions of the ODBC administrator.

This one is the 32 bit version:

C:\Windows\SysWOW64\odbcad32.exe

It can only see 32 bit drivers, and only 32 bit processes can see it's DSN's

This one is the 64 bit version:

C:\Windows\System32\odbcad32.exe

It can only see 64 bit drivers, and only 64 bit processes (i.e. SQL Server 64 bit) can see it's DSN's

Even better you could define a DNS-less connection which doesn't use a DSN, it uses the driver directly. Then you can avoid this confusing step altogether.

Answer 4

I would have used the Comment feature, but I do not have enough "Reputation Points" to do so.

The answer of SGeis, above, is on the money. It was hard for me to find such a clear, straightforward answer. Snapshots of the dialog boxes help immensely.

Let me add to his answer the following:

1. The Data Source fill-in (YourDatabaseName@YourInformixServerName) could be something as simple as Fred@Barney, rather than what I tried, namely, Fred@199.188.77.66 or Fred@199.188.77.66:32002 (the latter specifies a port/service number).

2. Once you create the linked server, if you go back into its General properties page, you will see that you cannot edit what you typed for Linked Server, Product Name (Why isn't this called "Provider Name," since Ifxoledbc is listed under Linked Servers/Providers in the Object Explorer tree?), Data Source, etc. So, if your connection fails because you mistyped something, it is unclear how to fix it.

Here is what you may do:

1. Right-click the linked server.

2. Beneath "Test Connection," look for "Script Linked Server as."

3. Click the latter, and, then, each of the following: "DROP And CREATE To" and "New Query Editor Window."

4. In the script text that appears, type replacement info for those settings that were grayed-out and uneditable.

5. Press F5 to run the script and thereby apply your changes. In doing so, the existing linked server is dropped, and a new one is created.

6. Open up your linked server's Security properties page and re-enter any connection password (even though asterisks -- suggesting that the password is filled and correct -- may appear in the corresponding entry). Also, examine the General properties page. Make sure that your changes stuck. Even though you ran the script and received no error, SQL Server will blank out fill-ins such as "Linked Server," "Product Name," and "Data Source" if, for example, you, as I did, had a brain aneurism and chose the wrong drop-down item for "Provider."

7. As noted above, click "Test Connection," to verify that your changes work.