Our understanding is 7.1 is also a new version - but we don't have it in our possession (see preceding about it being unavailable unless you order the OS upgrade). We should have it soon though. In a perfect world I could tell my clients they have to run with 6.1, but I can't dictate that to them. And what if other ISV's they work with weren't dictating the same release?
The data layer class library is a solution. I just think it shouldn't be necessary to make that investment. And it's an investment that everyone in a similar situation would have to make as well. Why would IBM want everybody to go through the same pain? Microsoft doesn't limit you to a single version of the framework so it would be overkill in a pure Microsoft solution to do anything like the same thing. You just state what version or versions of the framework need to be installed to run the application - it's common to do so and it's common that newer versions accommodate programs built over the previous versions or allow for concurrent versions to exist. IBM should recognize this and either be very specific in acknowledging that there are big differences in this respect between Microsoft .Net and IBM .Net so shops can make an informed decision as to whether even going .Net over the IBM i makes sense for them.
I do need the "cool stuff" in the ADO.net provider - it's one of the reasons we chose to develop .Net applications to modernize our IBM i applications. Scrapping it would mean serious losses in terms of efficiency in development.
I'm a big IBM i fan, I just think IBM just missed the boat with their scheme for updating it and I really hope they change that.
-----Original Message-----
From: systemidotnet-bounces@xxxxxxxxxxxx [mailto:systemidotnet-bounces@xxxxxxxxxxxx] On Behalf Of Richard Schoen
Sent: Wednesday, September 15, 2010 11:20 AM
To: systemidotnet@xxxxxxxxxxxx
Subject: Re: [SystemiDotNet] IBM ADO.net data provider version compatability
IBM hasn't frequently changed the version info.
There should really be only two versions to worry about:
Version: 10.0.0.0 for V5R3 and above.
Version: 12.0.0.0 for V6R1 and above.
You could develop a data layer class library for each one where the code
is exactly the same, but the .Net references match appropriately to the
DLL version.
You could also use the OLEDB provider which appears to be consistent
across the board but not as cool as the .Net provider.
On any development where we use Client Access/400 data drivers, we are
enforcing using the V6R1 driver as it works all the way back to V5R3.
Regards,
Richard Schoen
RJS Software Systems Inc.
Where Information Meets Innovation
Document Management, Workflow, Report Delivery, Forms and Business
Intelligence
Email: richard@xxxxxxxxxxxxxxx
Web Site:
http://www.rjssoftware.com
Tel: (952) 736-5800
Fax: (952) 736-5801
Toll Free: (888) RJSSOFT
----------------------------------------------------------------------
message: 1
date: Tue, 14 Sep 2010 16:47:53 -0500
from: Dave Jorgensen <djorgensen@xxxxxxxxxxxx>
subject: [SystemiDotNet] IBM ADO.net data provider version
compatibility
Because my company is a software vendor, IBM's unfortunate habit of
frequently changing versions on their ADO.net data provider is creating
big issues for us. I assume that there are other ISV's out there who
write .Net applications for the IBM i, so I'm hoping someone has worked
out a way to tackle this. I have asked IBM, but still don't have a
response.
--
This is the .net use with the System i (SystemiDotNet) mailing list
To post a message email: SystemiDotNet@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/systemidotnet
or email: SystemiDotNet-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/systemidotnet.
midrange.com
