If you can't find a solution for the IBM provider, what about the option
of using a third-party .NET data provider? Your clients have to pay for
licenses of Access, so it may not entail a much greater expense (unless
they need Access for other reasons). A lot of the third-party providers
are pure managed code, current with more recent .NET framework(s) and
features, and integrate with Visual Studio. If the licensing and cost
factors aren't prohibitive, you'd just have to get past the initial hurdle
of converting your client base away from the IBM provider. Here are a
couple providers that I know of, though I know nothing about their
licensing or cost:
http://www.hitsw.com/products_services/ritmo_net.html
http://web.datadirect.com/products/net/net-for-db2/index.html
Blake
------------------------------
date: Wed, 15 Sep 2010 09:47:51 -0500
from: Dave Jorgensen <djorgensen@xxxxxxxxxxxx>
subject: Re: [SystemiDotNet] IBM ADO.net data provider version
compatibility
Thanks for that - we did get some direction from IBM about your proposal.
This may be handy to know.
IBM says not to copy the data provider dll and include it with your
install, because all you get is that one .NET dll, you don't get anything
else that the .NET dll needs. So, if you have V7R1 installed on your
target PC, for instance, and in V7R1 they changed a COM component that the
.NET dll uses, you would still have a problem because the V5R4 version of
the data provider that you send with your application would be looking for
the V5R4 version of the COM component and wouldn't find it.
midrange.com
