Hi Art,
We were trying the DB2 .NET provider at the suggestion of the tech support engineer. Neither we nor the tech (who got online with us in a shared screen meeting) could find the .NET provider in the Informix CSDK.
After distilling down comments received publicly and privately, I have suggested to the developer that we "reboot" and start again, using OLEDB from CSDK 4.50.FC6. (If we can find it-- Fix Central seems to have only 4.10.* series; and that other marketing page seems not to have 4.50.FC6-- only 4.50.FC5. The link on the IIUG home page goes to the marketing page [which lacks FC6]. I always have trouble trying to find the latest Informix CSDK. I still don't know where to find 4.50.FC6.)
We are moving away from Informix for a combination of technical and political reasons.
Technically, it is mainly a matter of human resources. Informix used to be used by various other State of Alaska agencies. But, now, our agency is the only one left, I think. (There might be one other, but I haven't had contact with them for years, so don't know for sure.) In our agency, I am the "last man standing". No one else has any knowledge, experience, training, or even any exposure to Informix. The younger developers haven't even heard of it. They say stuff like, "Informix? What's that?" So, there's no one in the pipeline, so to speak, and that puts the agency at risk. When they wanted to hire, they couldn't find anyone suitable, without having to move someone up from the Lower 48. In addition, our hardware is another technical challenge. We run Solaris on Sun (my fingers don't like to type "Oracle") SPARC hardware. I'm the only one left familiar with that environment. It is obsolete, and needs to be replaced, and the decision was made that our agency will move to all Windows hardware, rather than having multiple platforms.
Politically, we face the lack of Informix mindshare. No one (at the decision-making levels) has heard of Informix. And, at the developer level, there are some who are actively hostile, continually whispering in management's ear that "real companies use real databases, like Oracle or MS SQL Server."
So, the decision was made to replace our existing hardware with Windows machines and to migrate to SQL Server.
That's it in a nutshell.
DG
------------------------------
David Grove
------------------------------
Original Message:
Sent: Wed August 11, 2021 08:03 AM
From: Art Kagel
Subject: .Net Provider connecting to MS SQL Server
The problem is the DB2 .NET provider. DB2's data types are different that Informix types so some types are problematic with that driver.
Use the Informix CSDK.
For information sake, why are you porting away from Informix? The cost of doing that is not usually worth it?
Art
Original Message:
Sent: 8/10/2021 8:50:00 PM
From: David Grove
Subject: .Net Provider connecting to MS SQL Server
Folks,
Unfortunately, we need to migrate from Informix (12.10.FC14) to MS SQL Server.
One of our developers is doing some very preliminary experiments.
We opened a tech support case to get assistance with acquiring and setting up a .Net Provider. We are working with a very helpful tech, and he pointed us to the IBM DB2 SDK that we are now using with a DRDA connection.
But, we are having difficulty with DATE, TIME, and CLOB/BLOB data types. The developer doing the experimenting believes that the problems lie with Informix because, as he says, DATE, TIME and CLOB/BLOB types are standard ANSI types, and that MS SQL Server easily transfers those types from other databases (such as Oracle and MySQL). But cannot do so from Informix.
I am not very familiar with databases other than Informix, so am a bit out of my league.
We had earlier tried to use the 4.50 CSDK, but had difficulties installing it. The tech suggested we use the DB2 SDK to get the .NET Provider from it.
We do expect to meet with the tech from tech support again, soon. But, it never hurts to also seek out additional knowledgeable sources.
Does anyone have an opinion concerning the most suitable .NET Provider for Informix 12.10.FC14? Or any tips on migrating the Informix DATE type. I am not expecting to find a painless migration from Informix DATETIME type, but was surprised to hear from the developer that DATE didn't work.
Thank you for any comments.
DG
------------------------------
David Grove
------------------------------
#Informix