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:




date: Wed, 15 Sep 2010 09:47:51 -0500
from: Dave Jorgensen <djorgensen@xxxxxxxxxxxx>
subject: Re: [SystemiDotNet] IBM ADO.net data provider version

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.

This thread ...

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2020 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].