Developing For .NET

One of the most popular posts on this site is about the iSeries .NET Managed Provider. In that post, I discussed a problem with an ObjectDisposedException being thrown at the end of every program that connects to a System i machine. The PTF solution promises to correct the problem on V5R3 machines and that the problem is automatically fixed on V5R4.

In the immortal words of Carol Kane, playing Miracle Max’s wife in The Princess Bride: “Liar! Li-Ar!” (I hope there are some TPB fans out there!)

If you hadn’t guessed, we tried it and it did not work. We upgraded one of our machines to V5R4 last week and upgraded the PC running iSeries Access to the V5R4 version to no avail: the error persists. My Business Partner is supposed to be looking into it, by which I mean that I need to tell him what PTFs I want. Frankly, I am looking at alternative solutions.

One possibility is to consider third party providers, Data Direct in particular. Data Direct’s Connect for ADO.NET product promises integration with every version of DB2 (including System i), Sybase, Oracle, and of course SQL Server. I have not looked at the code yet, but I was informed during one of our several phone conversations that the interface is a little different than strict ADO.NET, but it is consistent across all of Data Direct’s providers. The best news is that the providers are completely distributable along with our product if we purchase an OEM license. This means that unlike IBM’s solution which requires the customer to have and install at least some portion of iSeries Access V5R3 or higher, Data Direct’s solution does not require any additional installations. The bad news is that an OEM license would be very expensive. While they will tailor it to our company, I fear that it will ultimately cost too much. The license is naturally an annual fee, but once the company profits exceed an unspecified amount, the license fee becomes a percentage of the company’s revenues. All in all not a warm and fuzzy proposition.

Another option, that is contrary to all our previously stated goals, is to simply develop our new product line for SQL Server only. The good news about this idea is that all the tools and examples for rapid development take advantage of Visual Studio and .NET’s tight integration with SQL Server. I do think that the products would be easier to develop in this fashion. Another good thing is that if we design the architecture properly, we could make the switch to a database agnostic approach later without a lot of rework.

And the answer: I don’t know. In an effort to simply move forward, I am inclined to only consider SQL Server at the moment. I think this will relieve some initial headaches and speed development. But to appease our existing customer base, not to mention at least one of the company owners, we will ultimately have to address iSeries DB2 support.