That seems a policy problem on IBM.Data.DB2. Please try an assembly redirect.

<dependentAssembly xmlns="urn:schemas-microsoft-com:asm.v1">
     <assemblyIdentity name="IBM.Data.DB2" publicKeyToken="7c307b91aa13d208" culture="" />
     <bindingRedirect oldVersion="9.0.0.2" newVersion="8.?.?.?" />
</dependentAssembly>

The v9 ADO.NET provider is the ado.net provider for DB2, so there's no other one. However, it should be able to connect to older versions (up till v7) of DB2 (on unix/windows, not as/400), it simply connects to the DB through the DB2 client installed.

We have a build of the DQE in the runtimes which refers to an older DB2 provider, though there's no hard-reference from our linq provider to any DQE at all, so you are able to use that one in your code without problems. However using the latest DB2 connect should work properly, as it's the only .NET provider DB2 offers.

David: Thanks for the thought. I actually tried that before posting yesterday but didn't mention it. Exceptions in the IBM dll resulted, and it didn't seem likely that I could get it to work.

Frans: v9 isn't the only version. On a machine with DB2 Connect v8 installed, I have the following assembly: IBM.Data.DB2, Version=8.1.2.1, Culture=neutral, PublicKeyToken=7c307b91aa13d208. Drilling into this with Reflector reveals that it exposes ADO.NET types.

I can try throwing the v9 dll into my app's bin folder to see if that works on a machine with v8 DB2 Connect. I won't be able to get back to this for about a week, though, so I'll report back then.

On a related question, should I be able to get this to work through an ODBC connection to DB2? I realize the answer is probably, "why would you want to do that?" But please humor me.

Thanks!

Dave

Dave314159 wrote:

David: Thanks for the thought. I actually tried that before posting yesterday but didn't mention it. Exceptions in the IBM dll resulted, and it didn't seem likely that I could get it to work.

Frans: v9 isn't the only version. On a machine with DB2 Connect v8 installed, I have the following assembly: IBM.Data.DB2, Version=8.1.2.1, Culture=neutral, PublicKeyToken=7c307b91aa13d208. Drilling into this with Reflector reveals that it exposes ADO.NET types.

Every .NET provider of them does that? Anyway, in the v2.6 runtime lib DotNET20 folder, you'll find a folder called 'IBMDB2v8121', and in there you'll find a DB2 DQE assembly built with v8.1.2.1 as ADO.NET provider. You should reference that one in your project.

I can try throwing the v9 dll into my app's bin folder to see if that works on a machine with v8 DB2 Connect. I won't be able to get back to this for about a week, though, so I'll report back then.

That's likely not going to work, considering the way these companies use tight coupling between client versions and .net assemblies (so you then also have to upgrade the IBM DB2 client (the java stuff which is used under the hood)

On a related question, should I be able to get this to work through an ODBC connection to DB2? I realize the answer is probably, "why would you want to do that?" But please humor me. Dave

Heh no. ODBC is not going to work, sorry.

Frans, thanks very much for the quick reply. I think I might be misunderstanding you, because your two most recent posts seem to contradict each other. First:

Otis wrote:

The v9 ADO.NET provider is the ado.net provider for DB2, so there's no other one.

Then I said I had a different version--version 8. The reason I said that the assembly "exposes ADO.NET types" was to show that this dll was indeed an ADO.NET provider and not something else. And you said,

Otis wrote:

Every .NET provider of them does that

I don't understand how you can make a comment about "every .NET provider of them" after you said that there is only one.

The other thing I guess I misunderstood was:

Otis wrote:

it should be able to connect to older versions (up till v7) of DB2 (on unix/windows, not as/400), it simply connects to the DB through the DB2 client installed.

I thought you meant that the v9 dll should work through whatever DB2 Connect was installed on the machine, even if it's v8. But now I guess you meant that I would still need DB2 Connect v9 on the machine--you were just saying that the machine should be able to connect to a DB2 v8 database. That makes sense. However, our DB manager tells me that a configuration change is required on the mainframe in order to allow a v9 client to connect to a v8 database. They're not going to do that at this time, because any configuration change requires regression testing of existing apps, and they don't have that budgeted for this year.

Of course, the best part of your post is this:

Otis wrote:

in the v2.6 runtime lib DotNET20 folder, you'll find a folder called 'IBMDB2v8121', and in there you'll find a DB2 DQE assembly built with v8.1.2.1 as ADO.NET provider. You should reference that one in your project.

That's what I was really hoping to hear! I will give that a try next week.

Thanks again for your help! I know you're busy!

Dave

Dave314159 wrote:

Frans, thanks very much for the quick reply. I think I might be misunderstanding you, because your two most recent posts seem to contradict each other. First:

Otis wrote:

The v9 ADO.NET provider is the ado.net provider for DB2, so there's no other one.

Then I said I had a different version--version 8. The reason I said that the assembly "exposes ADO.NET types" was to show that this dll was indeed an ADO.NET provider and not something else. And you said,

Otis wrote:

Every .NET provider of them does that

I don't understand how you can make a comment about "every .NET provider of them" after you said that there is only one.

With '_the_' I meant: you can't download a provider for every DB2 version: there's just 1 to download. If you have an older one still lying around, use that one if you want to. The 8.1.2.1 build is for that situation: when people have v8 and don't want to download a new client connect version from IBM.

The other thing I guess I misunderstood was:

Otis wrote:

it should be able to connect to older versions (up till v7) of DB2 (on unix/windows, not as/400), it simply connects to the DB through the DB2 client installed.

I thought you meant that the v9 dll should work through whatever DB2 Connect was installed on the machine, even if it's v8. But now I guess you meant that I would still need DB2 Connect v9 on the machine--you were just saying that the machine should be able to connect to a DB2 v8 database. That makes sense. However, our DB manager tells me that a configuration change is required on the mainframe in order to allow a v9 client to connect to a v8 database. They're not going to do that at this time, because any configuration change requires regression testing of existing apps, and they don't have that budgeted for this year.

Ok, I just rehash what IBM says in their list of supported systems but indeed it could require a change on the DB side, that's not uncommon for DB2. As DB2 and also oracle use a java / C client with on top of that a .NET wrapper, it is mandatory that if you want to use .NET provider assembly v9, you need the underlying client code also installed.

So as you're using v8, simply reference the DQE build for v8.1.2.1 instead of the v9 one.

Of course, the best part of your post is this:

Otis wrote:

in the v2.6 runtime lib DotNET20 folder, you'll find a folder called 'IBMDB2v8121', and in there you'll find a DB2 DQE assembly built with v8.1.2.1 as ADO.NET provider. You should reference that one in your project.

That's what I was really hoping to hear! I will give that a try next week. Thanks again for your help! I know you're busy! Dave

All good, Frans. Thanks again for your time. I will try this next week and report back.

Dave