Windows 8 Developer Preview build contains the complete fix of the ADO typelib issue

Question

[Important Note: I open this new thread because the original thread is already too long. Hopefully everyone will reply to this new thread for more effective communication. We will monitor this new thread for new issues and discussion, but not the old thread. The original thread is at: http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13?prof=required]

 

The Windows 8 Preview build contains the complete fix of this issue. Please download the Preview build freely at: http://msdn.microsoft.com/en-us/windows/apps/br229516. (However, please note that there is no customer support if you got any problem with the Windows 8 Preview build - so please only install the build on your test machines, but not your business-important machines).

In the preview build, what we have done are:

- Pull out the 6.0 typelib from Win7 RTM and ship it via the new typelib file: msado60.tlb. Ship a new 6.1 typelib (which contains both new and deprecated interfaces) and embed it inside the msado15.dll. Revert back all 2.x typelibs to what they looked like as in Win7 RTM. Therefore, the 2.x and 6.0 typelib are used for backward compatible purpose, and the 6.1 typelib is used for 64-bit VBA solutions. You are advised to migrate to the 6.1 typelib whenever there is no more downlevel support concern for your applications. This fixes the recompilation issue (as reported in the forum thread: http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13?prof=required).

- We also fixed the thread handle leak issue in ADO Async execution mode (as reported in the forum thread: http://social.msdn.microsoft.com/Forums/en/sqldataaccess/thread/68e23681-f6b5-4ed5-b963-e63e34eeac2f)

- msadoR15.dll has been reverted back to what it looks like in Win7 RTM. Since this binary is deprecated, there is no new interfaces introduced for ADOR. btw, customers are advised to migrate to ADO interfaces (actually, ADOR is simply a subset of ADO). This issue is reported in the forum thread: http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13?prof=required.

- The application (with JRO) cannot run  properly (as reported in the forum thread: http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13?prof=required)

- COM+ marshalling scenario (as reported in the forum thread: http://social.msdn.microsoft.com/Forums/en-NZ/windowsgeneraldevelopmentissues/thread/0a0fa3b8-9334-45a3-8405-44e6f969c46f)

- Some other internally reported issues.

 

With the newly-implemented solution, if customers require downlevel support, they should compile their applications with the 6.0 typelib (or 2.x typelib). [btw, 2.x typelibs are deprecated, so we advise our customers to use the 6.0 typelib]. Whenever the downlevel support requirement are gone in the future (say, those downlevel platforms are not relevant anymore as times goes on), customers should seriously consider to migrate to the 6.1 typelib, which is the only supported typelib in the future.

If your applications (VBA, VB6, .NET) are referencing the 6.0 (or below) typelib, you can simply recompile your application on the Windows 8 Preview build and then your application should now work on downlevel platforms as well. If you are using C++ and using "import msado15.dll", you have to change the reference to "msado60.tlb" in your code and recompile to get downlevel platform compatibility. If you are using C++ and using "include header method", you have to use the latest Win8 SDK and target your applications to downlevel, in order to obtain the backward compatibility behavior (see the Visual Studio setting for more detail on how to target downlevel platforms) [Please note that VB6 and .NET ADO interop are not supported anymore. This forum post does not imply any future support of these out-of-support technologies.]

So, I hope everyone who has impacted by this issue to try out the Windows 8 Preview build as soon as possible. Report any new (un-addressed) issues to us, so that we can address them in the Windows 8 RTM build. Your feedback is very important to the success of the Windows 8.

=========

We are still actively looking at whether / how to ship the fixes on Windows 7 SP1 (and other downlevel platforms). Therefore, please stay tuned. We will announce once we got more information on the downlevel fixes. In the mean time, please try the Windows 8 Preview build first.

 

Sorry for any inconvenience caused by this issue and hopefully the Windows 8 fix can address your problem.

 

Thanks,
Ming.
WDAC Team, Microsoft.

 

---

Pak-Ming Cheung - MSFT

Answer 1

Will these changes fix problems in MS Access?

Answer 2

What are you guys thinking about?

You have directed two former threads to this one. The largest of these two threads was dealing with fact that recompiling ADO based code on Windows 7 SP1 resulted in applications that were unusable on anything but SP1. I can only imagine that your suggestion that the answer to this is to compile on what appears to be a pre-alpha version of Windows 8 will be met with scorn.

The other old thread ( Has Windows 7 Service Pack 1 broken ADO based COM+ Applications) was to do with the fact that any applications that were built around the ADOR library simply did not work in Windows 7 SP1. The fact that apparently they will will work in Windows 8 preview is almost completely irrelevant. (Yes it's nice to know that this problem might not exist in software to be released in a year or two, but what we need is a solution now!).

I appreciate that you are still working on SP1 fix but then why on earth have you decide to 'stop monitoring' the old threads where these issues were raised.

I am sure Windows 8 will be great, but frankly I am more concerned about solving the issues with Windows 7.

 

 

Answer 3

Please be more specific on what problem in MS Access you are seeing. This will only fix the issue introduced in Win7 SP1 about ADO typelib.

If you had a problem with ADO typelib and that made your VBA application didn't worked, I believe the Windows 8 Developer Preview build has already resolved your issue.

But if you are talking about other MS Access issue, it is probably not fixed yet (actually, those issues may not be related to WDAC at all). So, you are advised to contact the Office customer support, or post on the Office forum for help.

 

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 4

The original thread about "recompilation" is extremely long. It takes a whole minute to open that thread in my machine and it is not searchable anymore. Therefore, the intention for opening this new thread is to make the communication easier and faster. This does not mean that we are going to ignore the original Win7 SP1 issue. Please understand.

Actually, I was posting to ask all the impacted people to test on the Preview build and report all un-addressed issues to us as soon as possible. If we are going to fix the Win7 SP1, we will probably port the entire fix to Win7 SP1 directly. Therefore, it is very important to test the Preview release to ensure the quality of the Windows 8 release, as well as the Win7 SP1 release (if any).

As always, I cannot talk too much about the SP1 news in the forum because of internal policy. But we are actually working on the SP1 and investigating whether we can ship a fix for SP1. We will announce once we get more information. Please stay tuned.

 

Thanks,
Ming.
WDAC Team, Microsoft.

 

---

Pak-Ming Cheung - MSFT

Answer 5

Is it possible to split one thread into more pages as we can see in other (non-MSFT) forums?

Answer 6

I might be convinced if the title of this thread was not all about Windows 8. If all you wanted was a new thread to address the original problems why isn't called 'ADO issues in Windows 7 : A new start', or something like that?

Besides recompiling in the Windows 8 preview isn't going to help with the broken ADOR applications.

Answer 7

It's a real rigmarole to fire up a VPC and install the Windows 8 preview just to get the corrected typelib. Do you have a link to download only the corrected typelib that fixes a Win7 SP1 machine?

---

Price Brattin, SQLServer & SharePoint 2010 MCP, Microsoft Dynamics SL Consultant

Answer 8

Unfortunately, copying the Win8 typelib to Win7 SP1 is not supported. And there is no way to download the corrected typelib to Win7 SP1.

I would like to ask your help to fire up a VPC and install the Win8 preview for a simple testing. If it works for your scenario, you can remove the VPC immediately if you don't want to try any other Win8 features.

 

Thanks,
Ming.
WDAC Team, Microsoft.

 

---

Pak-Ming Cheung - MSFT

Answer 9

I guess I am missing the objective. If "copying the Win8 typelib to Win7 SP1 is not supported", then what is the purpose of installing the Win8 preview? If our production development machines are Win7 and we cannot copy the typelib from the Win8 preview, how would our problem with the Win7 SP1 typelib be fixed with anything that is in the Win8 preview?

---

Price Brattin, SQLServer & SharePoint 2010 MCP, Microsoft Dynamics SL Consultant

Answer 10

Are you crazy?  Install a beta version of new operating system just to fix a problem introduced by Microsoft itself?  That is like amputating my left arm to cure a hangnail.  C'mon Microsoft, you can do better than this.

---

Miles Gibson

Answer 11

Thanks for the long delayed fix for the thread handle leak issue in ADO Async execution mode. 

I can confirm it is fixed in the Windows 8 preview build, tested with the small async application I wrote back in March.

However |'m disappointed this serious bug has still not been acknowledged in a Knowledgebase article, or fixed, particularly since your fix of rolling back to Windows 7 RTM would seem so easy. 

For anyone else attempting to install the preview build, don''t bother with Windows 7 Virtual PC, it does not support 64-bit VMs and even the W8 32-bit version fails with a HAL error during set-up.  I installed Virtualbox instead, which works a treat.

Now I just need to change the Windows 8 styles to make i t look like Windows 2000 again, so sanity is restored <g>

The God Mode menu was the first thing I installed so I can find things.

Angus

 

 

---

Angus Robertson - Magenta Systems Ltd

Answer 12

I don't really understand how this helps Win7 developers. It's great that the fix works for Win8 beta users. But what about those of us who are using released OS and service packs? Is a patch or update coming to fix this for those of us using Win7? If not a patch, can we get a workaround / set of instructions that would allow developers to compile applications safely in Win7 SP1?

Currently my whole office is on either XP or Win7 SP1. The only way I've been able to compile MS Access (.ade) applications that work on all computers in the office is to maintain a Win7 RTM environment and avoid Win7 SP1.

Answer 13

Thanks Pak-ming, this looks like the right approach to the problem. I will test this later this week and let you know how it works in my situation.

To complete this we need execution on Win 7. By giving priority on Win 8 it suggests we need to wait a long time to get a solution. Hopefully that is not the case. The correct full approach would look like the win 8 solution with:

1: a hotfix for win 7  sp1

2: a permanent solution in sp2

both leading to the same state, revert to win 7 typelibs and a new 6.1 typelib for 64 bit only

Hope to hear from you soon, Pieter

Answer 14

Yes - we will be porting this change to Windows 7 SP1 with a release timeframe targeted at early next year.  We are also in the process of evaluating the need for this to be ported to other OSes.

Answer 15

Yes - we will be porting this change to Windows 7 SP1 with a release timeframe targeted at early next year.  We are also in the process of evaluating the need for this to be ported to other OSes.

If I remember correctly, this design bug was reported six months ago.  It will take another six months to port the "fix" to Windows 7 Sp1?

Will someone please explain why it will take a year to create a hotfix that rolls back a few typelibs?  Is this a gambit to force developers to troubleshoot Windows 8?

---

http://www.saberman.com

Answer 16

Yes - we will be porting this change to Windows 7 SP1 with a release timeframe targeted at early next year.  We are also in the process of evaluating the need for this to be ported to other OSes.

This just takes the biscuit! It is evident that you guys care nothing for your customers. I asked back in May whether the ADOR issue was going to be resolved so that we could address issues with upgrades to SP1. For five months I have been strung along with promises of 'We are working on it'. Now suddenly Windows 8 preview appears with a fix, but the fix we all require (to SP1) isn't going to be available until NEXT YEAR!!! It is obviously time to give up on this.

Why don't you sort out the problems with what people are expected to actually use before shouting about the 'wonders' of something that is way down the road for most?

 

Answer 17

We definitely understand the most-impacted release is the Windows 7 SP1, but not Windows 8.

 

However, the fix is not simply to revert back those typelib(s). It also involves something else that we didn't explicitly mentioned in the previous forum posts. For example, this involves code changes in multiple DLL (such as ADO, ADOR, ADOMD, MSJRO, etc.). Frankly speaking, this is actually a relatively big code & design changes. Also, there are a lot of scenarios that require testing (VBA, VBScript, C++, marshalling, etc.), as well as some out-of-support technologies (such as VB6 and .NET interop) which are difficult to automate. Therefore, please understand that this would require extensive design / coding / testing effort.

 

Normally, we won't ship such a big design change via QFE, but only ship it via the next SP (in this case, this is the Win7 SP2). However, we still don't know the SP2 schedule and given the huge customer impact on Win7 SP1, we are seriously considering to ship the fix via a QFE for Win7 SP1. But before shipping the QFE, we would like to hear whether there is any unaddressed problem in the new design. That's why we asked our customers / partners to test on the Win8 platform first.

 

If everything on Win8 looks good, we will be more confident to port the Win8 fix to the Win7 SP1 and ship the QFE. Therefore, we can process the SP1 fix earlier, if we hear your feedback on Win8 build earlier. In case if possible, we would release the SP1 fix earlier.

 

Thanks,
Ming.
WDAC Team, Microsoft.

 

---

Pak-Ming Cheung - MSFT

Answer 18

It should be easier to revert back the whole SP1. It wouldn't take much time, I suppose.

Answer 19

Ming,

I can confirm that this works for my situation which is VB6 with MS Data Environment and ADO 2.8. I compiled a dll and inserted it in my app on a Windows XP professional. It ran without problems.

Installing VB6 gave me a hard time, as the install seems to hang. Also the Data Environment dlls can not be registered. Even though I logged in as an administrator, the commands do not execute as Administrator. For example run, regsvr32, did not have the right permissions to register a dll. Starting a command prompt, run as administrator, and then do regsvr32 from there solved that problem.

I still was not able to install the SP6 of VB6, it terminates with an "Installation was unsuccessful" message.

But the good news is the Typelib solution worked.

Pieter

Answer 20

Help!... So i am getting ready to distribute a new update to our product. 

But, based upon what I am reading, there is still no resolution (even after 9 mos?) for this ADO issue?

How can my clients and I get around this?  Going to build under Win8.0 (or compiled) - is not an option.  Is there any way to move forward with Win7 Sp1 and to use the ADO OCX?

Answer 21

So, I have taken a quick look at a downloaded version of msadodc.ocx (which seems not to be shipped since Vista time). From the OleView tools, it seems that it is referencing the ADO 2.0 typelib (msado20.tlb).

So, are you using it under VB6?

 

For this case, the only available workarounds are:

- Using downlevel windows (say, Windows Vista, Windows 7 RTM)

- Using Windows 8 PDC build

- Installing the XP-Mode on top of Windows 7 SP1

 

Thanks,
Ming.
WDAC Team, Microsoft.

 

 

---

Pak-Ming Cheung - MSFT

Answer 22

I'd like to try this hotfix: http://support.microsoft.com/kb/983246

But how to obtain it? The link at the top of page goes to a generic MS support page.

Can you help me?

has anyone tried this hotfix ?

Thanks.

 

---

Riccardo

Answer 23

I'd like to try this hotfix: http://support.microsoft.com/kb/983246

But how to obtain it? The link at the top of page goes to a generic MS support page.

Can you help me?

has anyone tried this hotfix ?

Thanks.

 

---

Riccardo

This hotfix is surpassed by the fix in Windows 7 SP1 64 bits, which then caused the problem that we are discussing in this forum.

Answer 24

OK. I just stumbled upon that thread and finally found what was the cause of the compatibility issues that's been giving me headaches and sleepless nights for the past five days, going back and forth between our dev & client machines (not counting useless debug builds / stack traces / remote debugging sessions and finally building a few different VMs with the whole dev. suite each to replicate the different environments) and then to realize with astonishment that the same source code, linked with the same typelibs-with identical GUIDs & ProgIDs!!-just would work on some computers but not others. I never thought fixing a simple bug in one of our own software & recompiling it would have me bang my head against the wall so much I tough I was going crazy.

I'm relieved I finally found the answer, but quite annoyed such important change was made without much documentation-well, yes, for the fix it provides but not for the leaps of codes this "design"-fix breaks. Am I the only one for whom this went under the radar, or was the break really documented?

Anyway, I have a question. And I am surprised, seeing this issue's been known for months (!), that nobody though about it. Doesn't Window's component store ("Windows Side by Side") keep every single version of components changed through updates and hotfixes? Even if our Windows 7 machines have SP1 installed, shouldn't they still have previous versions of the ADO typelibs, binaries & all? Why would I need to download ~5GB worth of another OS (and of alpha code, mind you!), risk rolling back my machines to a pre-SP1 state or even be forced to crawl the tubes for a Windows 7 RTM disk? (our systems are all OEMs) Then it shouldn't be too hard to rollback just those components, no? I mean, in our case we're not using 64-bit editions of Office 2010 anyway.

Answer 25

OK. I just stumbled upon that thread and finally found what was the cause of the compatibility issues that's been giving me headaches and sleepless nights for the past five days, ..... Am I the only one for whom this went under the radar, or was the break really documented?

Hi Jim,

 

Nope, most of us found this out exactly like you did or if we were lucky we read about it on a few of the developer's forumns / email lists back in Jan/Feb 2011.  This list (well, the original one) was my main source of info on what was happening with this.  To be frank, Microsoft's veneer thin communication (and dare I say, lack of initial TESTING!) on this issue has surprised me.  Maybe it surprised them more, dunno.

I know that code is complex and we all make mistakes, but honestly, this one has been been a right stuff up for many folks.  Plenty of us have lost many hours of fruitless debugging and some face with our clients as solutions that have worked fine for years would suddenly fail and the developer has no idea why there is suddenly a problem.  Clients don't want reasons or excuses, they want solutions.

For the first time in nearly a year there seems to be some suggestion that MS are actually taking this issue seriously and working on a realistic and permanent solution - inparticular for folks who are VBA developers.

Answer 26

Hi again. To report back on my issues and the solution I picked, I decided to go with method #1 described at http://support.microsoft.com/kb/2517589, that is install and use on my Windows 7 SP1 machines the back-compatible typelibs provided, and so far it's been working for me.

That seemed the best solution anyway. I just couldn't switch to late binding, since that would have meant *lots* of manual code changes (a quick grep told me I had about ~230 references in that single project I was updating). Also, although I don't know if there exists yet an update for OSes prior to Vista to bring them on par with the changes made to the ADO interfaces (after all, this is to correct a problem on 64-bit OSes), I gave a thought about it. Not only this change/update will have to propagate to down-level OSes, but also *all* softwares using ADO, even legacy ones, will have to be recompiled with those new interfaces (unless, of course, they were using late binding). In my case, we have another application accessing the database also built in VB6 (but not by us) that uses ADO as well, and I doubt we could have it recompiled.

So, well, yes, I'm glad they provided with those typelibs.

Oh, and by the way my name is Jonathan Brochu (don't mind that Live ID)

Answer 27

I am glad I found this discussion.  Now I understand a very vexing problem that has cost me credibility with my clients.

Pak-Ming, do you and Microsoft get it that W7 SP1 has broken Office 2010 VBA applications for our clients who use anything less than Windows 7 SP1?

I develop Office VBA applications, including the 2010 versions of Excel and Access.  What strikes me is that the Win 7 SP1 warning notice and various MS responses to this and the original thread sometimes imply that VB6 developers should move on, and that some older applications might not work right. 

If you're developing for Office 2010, there's no place to move on to.  That's the latest. MS has broken it for me.  If you develop for Office 2010 and your clients don't update to SP1, you are in a really tough position trying to explain why your application isn't working for them.  They (rightfully) don't care about technical issues, they just want things to work.

I can't just tell my clients to update to W7 SP1.  My customers are corporate clients who have no control over their computers.  Their IT departments control their computers.  And asking their IT dept to deploy a service pack (or a hotfix) for a custom application until IT is good and ready?  Does not happen.

My current development computer was bought in July.  It came with SP1.  I'd uninstall SP1 but I can't, because came with my computer.  That's MS talking, and they're right about that.

This thread has been very helpful.  I am amazed and outraged that Microsoft would actually break applications developed for their latest version of Office.

And it is even more amazing that:

1.  The original thread started in February 2011, (8 months ago), and no fix has been released.  Just work-arounds that don't work.

2.  The title of this thread and the suggested solution from Microsoft is to install a pre-beta build of Windows 8!  Really? On my production machine??!! Pre-Beta? (Oh, and by the way: "Please note that there is no customer support..., the bold is in the top post).  Gotta be kidding me.  If merely a first service pack to Win 7 caused such problems, why in the world would I trust a pre-beta of Win 8? Unbelievable.

MS is saying: Here's a solution, but we don't support it, and don't use it on "your business-important machines".

Amazing.  I wouldn't care so much if it weren't "business-important".

 

Charlie

 

 

Answer 28

I second Charlie's point. It is incredibly negligent of Microsoft to knowingly release this and not move quickly to fix the problem. I am using ADODB within Excel VBA. Each time the spreadsheet is saved on a Windows 7 64 bit machine then open it on a Windows XP 32 bit machine it is broken. Asking people on 32 bit machines to open the VBA IDE and choose Tools -> References, uncheck a reference , then OK then recheck a reference is not feasible. Most of my users are computer novices i.e. if the shortcut to the Excel file moves position on there desktop I generally get a call to find it for them, so this is not a workable solution.

 

Please provide a workable fix for this ASAP.

 

Ben

Answer 29

Hi Pak-Ming

I need to know the impact, if any, with Excel VBA.

The ...Backcompat typelib is not a solution as the deployed machine will probably not possess that typelib and testing this gives an error during Open if the typelib is missing, which suggests that Excel VBA's references are "compiled" at run time or at least on file open.

This forum's and the original forum's messages suggest that early binding is a solution. However, as the referenced ADO library is not resolved until run time with Excel VBA perhaps early and late binding will make no difference to this problem? And, taking this further, if the Excel VBA does not store the "new" GUIDs when "compiled" on a Win7 SP1 system, perhaps the problem will never occur with Excel VBA?

We are trying to plan a "safe" strategy for Excel VBA "apps" in the event that our development or client machines have Win7 SP1.

Thanks for your attention.

Jeff

Answer 30

Jeff,

 

Yes, the backcompat typelib won't work for VBA scenario.

There was a suggestion to change your code to use late binding, rather than early binding, with the 6.0 typelib reference. It sounds like it would involve a very big chunk of code changes and it can potentially result in performance issue, so this is not recommended anymore.

For VBA application developers, the current safest strategy is still the following:
1) Using downlevel windows (say, Windows Vista, Windows 7 RTM)
2) Using Windows 8 PDC build
3) Installing the XP-Mode on top of Windows 7 SP1

If this issue is critical to your business and the above workarounds do not work for you, please contact the Microsoft Customer Support so that we can probably address your issue better.

 

Thanks,
Ming.
WDAC Team, Microsoft.

 

 

 

---

Pak-Ming Cheung - MSFT

Answer 31

For the many people reading this thread who are NOT using VBA, here is a link to the backcompat typelib mentioned in the last two posts: http://support.microsoft.com/kb/2517589

It really blows my mind that no one has mentioned that already.  Unless I'm missing something, this thread has made it sound like there is not already an easy solution to this problem (excepting those who are using VBA as noted in Pak-Ming's previous post).  Having said that, we are just now implementing this solution so... hopefully it's as simple as it seems to be.

 

Pak-Ming: I would like to reiterate to you what many have already expressed in this thread.  When we come looking for a fix to an immediate problem, don't ask us to help you test something that's not even related to our problem.  And by not related, I mean that our efforts in helping you test will not bring us any closer to fixing our issue therefore it's not related.  Our problem is right now, not months out in the future.  Therefore any fix that takes that long is not going to be helpful to us.  Help us with our immediate needs first, then we would be much more obliged to help you with yours.

Answer 32

I also woujld like to reiterate a question that has been asked before: What is the freakin' hold-up?! Why is MS not releasing a fix for this problem that creates havoc for all of us who make a living developing software for the MS platform? For cryin' out loud! It's been over six months! How long does it take?!

Just tell us what is holding up delivery of a fix.

---

Price Brattin, SQLServer & SharePoint 2010 MCP, Microsoft Dynamics SL Consultant

Answer 33

For VBA developers, I'm testing a work-around.  I'm interested in getting feedback on the approach.

Using Excel as an example, when the workbook is opened, I use the Workbook_Open event to check the version of Windows.  If it is Win 7 SP1 (Build 7601), no action is required.

If it is not Win 7 SP1, code is then executed to remove the reference to the ADO type library, and then to add the reference back in.

This seems to re-establish a working connection to the library on the target machine.

The code required is pretty small.  It's very fast, and the user doesn't see anything.

A disadvantage is that the user has to set Excel trust settings to "Trust access to the VBA project object model", but that is easy and is a one-time thing.

I would just roll back SP1, but my development machine was purchased in July, so came with SP1.  It can't be rolled back without re-installing Windows.

Input appreciated.  I'm happy to share the code if it would be of use.

Charlie Almquist

Answer 34

Thank you Brandon for your post ,

But I already try this fix and it not works for me. I'm telling about VB6 applications using ADO and compiling in a W7 32 SP1 environment: it don't work.

I would also like to sign your comment to Pak-Ming.

---

Riccardo

Answer 35

Pak-Ming,

I notice that MS has given the ADO 6.1 version typelib for Win8 beta. What would you give the version number for Win7,....ADO 6.2? (if there intention for a fix).

That I would believed may cause confusion along the way. I would suggest that MS rename "ADO 6.1" to "ADO 7.0" instead, that way you can indentify the typelib for Win8 and leave "ADO 6.1" as for Win7 fix solution.

Answer 36

AccessVandal,

 

In the planned fix for Win7, we are still going to publish the 6.1 typelib. Basically, you can assume that the Win7 fix is very similar to that on Win8 fix. Basically, both Win7 and Win8 should use the same version for the new platform-independent typelib (6.1 here), so that application leveraging new interfaces can work on both Win7 and Win8.

[Declaimer: Since this was not yet officially published, everything is up to change.]

 

Thanks,
Ming.
WDAC Team, Microsoft.

 

---

Pak-Ming Cheung - MSFT

Answer 37

Pak-Ming,

 

Just so I'm clear here, as of today, then, there remains no fix for this ADO Typelib issue for those with Windows 7SP1 who are VBA developers other than 'don't do that'/'revert to Pre Win7-Sp1 downlevel OS'. Correct?

 

Is 'sometime early next year' still the best available estimate for an available ADO library fix for Win7Sp1? ...or will this wind up in Sp2?

There is a growing list of we Access/VBA developers growing increasingly restive for a fix - *any* fix - to this mess you folks dumped on us.

 

---

Mark Burns, MCAD, MCP
Sr. Microsoft Access Analyst/Developer
Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN) - 2200+ member developers and counting

Answer 38

Mark,

On 10/20, I posted a VBA workaround that seems to work.  It's not a fix, but at least in the one instance I've tried it with Excel, it worked.  I'd be interested in your comments on the approach.

I'm dumfounded by the fact that Microsoft - apparently knowingly - dropped this bomb, and that they still haven't fixed it after ten months.

Charlie Almquist

Answer 39

Charlie,

I can give you a reply regarding Microsoft Access applications wich also use VBA. Your mentioned ADODB re-reference workaround is unfortunately not possible, if you deploy 'compiled' Microsoft Access databases (accde-/mde-files).

Axel

Answer 40

Axel,

Thanks for the information.  I don't have experience with compiled databases in Access.  Good to know.

Charlie

Answer 41

Hi Ming,

I wanted to post a confirmation that this change in the Windows 8 build fixes the problems I was having with ADO in Win 7 SP1.

To be specific, we have a VB6 class library that has some public methods that return ADO recordsets. This library is set up with binary compatibility. When trying to recompile on a Win 7 SP1 system, VB6 complains that the methods returning the recordsets are no longer binarily compatible. With the Win 8 build, there was no such problem.

Hopefully your team can provide a similar fix on Win 7, as most Win 7 machines are coming pre-installed with SP1 these days (making it a headache for new developers).

Looking forward to hearing more.

Brian

Answer 42

Hi all,

Just to confirm the VBA/Access (2007) workaround I have found I have to do with Access...

• Load my access db into access within a XP VM running on my win7sp1 development machine, and open up the code editor
• If the db is already in a compiled state, make a change (any change e.g. add a blank line and delete it) to put into a decompiled state.
• Note that I make sure I do this in a code module with code that is affected by the ado problem. I have done this in a non relevant module and (assuming I didnt miss something else out) I have had an instance of it not making any difference when updating references. Probably me! Anyway...
• Further Note that if I DON'T do the above, then I have removed/added references and had the db still not work.
• Compile the DB - make sure I get an error
• Remove a reference from the references pop up window (even if all are showing as ok), and close the references pop up window
• Go back in and readd the reference
• Note if I DON'T close the references pop up window between removing and adding a reference, then my updating of references don't work. I guess doing the above forces a refresh of all references
• Compile db - all works with no errors
• Make .accde version etc. for distribution
• Take pain killers for large `pain in the arse` that this is

M.

Answer 43

Any update available?  Leaving our machines without Windows 7 SP1 now means we cannot install the Microsoft SQL Server 2012 Release Candidate 0.  When you run that setup program you get error:

The operating system on this computer does not meet the minimum requirements for SQL Server 201 RC0.  For Windows Vista or Windows Server 2008 operating systems, Service Pack 2 or later is required.  For Windows 7 or Windows Server 2008 R2, Service Pack 1 or later is required.  For more information, see Hardware and Software Requirements for installing SQL Server 2012 RC0 at:  http://go.microsoft.com/fwlink/?LinkID=195092

Ming, can you find out why the SQL team is requiring SP1 which we cannot run when all server 2008 needs is SP2? 

This is a real problem for me.  Now my developers cannot test our products with SQL 2012! 

Can you please discuss this with the SQL Team or put more pressure on the Windows team for an SP2?

 

Darren

---

Darren

Answer 44

Darren,

Could you try Windows Server 2008 SP2, which is not impacted by the ADO issue?

Thanks,
Ming.
WDAC Team, Microsoft.

 

---

Pak-Ming Cheung - MSFT

Answer 45

I have tried couple of scenarios described  in this thread and the previous one, but could not succeed.

So my question is, like many others wrote here, when will be this so called so late fix will be available ?, so that this nightmare, maintaining development machines of older OS versions or beta versions of future products just to make a compile run ends?

This is a hot issue, planning to roll it with a service pack along with other updates is a bad idea, work on this problem specifically and issue an update.

I know you are working on the problem, but it is not enough. At this point it is clear that the engineers in MS disposal, responsible for this task either not enough in numbers, or quality. Sad but true.

 

 

Answer 46

@ Pak-Ming,

I've been following this problem now since feb. 2010!

Is there a fix coming??? Can't be that it takes this long!!!!

 

Hope to hear some goog news, cause my develop pc is still Win 7 without SP1... can't update!!!

 

p_sie

Answer 47

Please update us with regards to the time frame of a fix for Windows 7 SP1 and VBA.

This is a major headache and MS need to respond to it's loyal developers.  We are your evangelists and you are leaving us out in the cold.

Please help!

Answer 48

 

I'll repeat what I stated in August (on the previous thread):

http://social.msdn.microsoft.com/http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/3a4ce946-effa-4f77-98a6-34f11c6b5a13

MS wins by inaction!

That MS itself broke the rules of COM and then tried to justify the change, is pure arrogance on their part. Sure, some staff are concerned for us developers but to have let this go on for such a period of time - causing incredible amounts of grief to their, once, loyal following of developers - just defies belief.

Yes, there are so-called workarounds (non that are acceptable given the root cause of the issue) and we continue to suffer. I wonder how many developers have now been forced to update their customers to Windows 7 SP1 from other operating systems (M$ just loves that!) because the situation for them is untenable? More than a few, I bet. Or even worse, (as is my case) forced to keep his teams developer machines running pre Win 7 SP1 OSs (because it's just so much easier!).

This has been nothing but a nightmare since Feb 2011 (getting close to a year!). MS releases so-called "priority" security fixes almost on whim but this fix (already in Win 8, remember) has not been available in Win 7. Why?

I'm fed up.

We have been a loyal MS shop since MD-DOS days and, probably like most developers on this forum, locked into MS products. However, we are now looking into alternatives wherever possible. We may not be able to change the OS or the language tools we use for development but we can change the database, mail systems etc. that we use - and shall.

And we're all still waiting for a fix...

 

 

---

gbc

Answer 49

Since Pak-Ming seems to be busy with other issues I'll post the only real answer there has been so far:

http://blogs.msdn.com/b/psssql/archive/2011/10/03/yes-we-made-a-mistake-and-are-finally-going-to-fix-it.aspx

Interestingly it says:

Unfortunately, we drastically underestimated the number of customers who were recompiling ADO applications on Windows 7 SP1. Even worse, when I say drastically, I really mean DRASTICALLY.

This was posted back in October 2011 but does not seem to have been widely noticed, aside from being mentioned on at least one Access developers blog.

As to when we might expect a fix it the post says:

Although you can see this fix in action in the Windows 8 Preview we shipped in September, we won’t be able to deliver the Windows 7 SP1 fix until early next year. As you can imagine, we are checking and re-checking everything because we completely understand that the only thing worse than no fix at this point would be another incomplete fix that requires yet another direction shift and another significant delay.

Answer 50

Thanks for that link....I had not run across it before.

Answer 51

Yes, thank you Steven. This is an informative blog entry; I'm surprised that no one from Microsoft has posted it to this thread (or the original one).

Answer 52

It should be noted that this problem was reported in November 2010 and that there were reports of it in the SP1 beta (see the earlier thread if you can get Explorer to render it).

>We are still working hard to try to deliver this fix even sooner than early next year, but at this point I am not able to make any promises for an earlier delivery.

It appears they were not able to deliver it sooner.  Let us hope it will still be early this year.

>What happened is that we realized that some of our ADO APIs used platform dependent data types..  This caused problems when 64-bit applications tried to consume these platform dependent data types and the caller’s data type did not match that of the callee’s.

If this was the rational for breaking ADO it makes no sense.  If you are developing code that will run in both x86 and x64 you are supposed to use #IF to define the types and interfaces two ways -- one for x86 and one for x64.

---

http://www.saberman.com

Answer 53

The original ADO interfaces have different meaning when being compiled with different bitness, thus breaks COM rules. The problem first surfaced with Office 64bit and VBA but could be any COM client and server that reference the problematic ADO type library.

Of course for well-known COM servers like Access.Application you can check bitness of the server using other ways before deciding which interface to use, but this is the exception, not the rule. The COM server may be running on another machine, while the only interface you have is the broken COM interface.

 

---

---

The following is signature, not part of post
Please mark the post answered your question as the answer, and mark other helpful posts as helpful, so they will appear differently to other users who are visiting your thread for the same problem.
Visual C++ MVP

Answer 54

Pieter,

I am currently trying to install vb6 on Windows 8 so i too can compile and use my vb apps on XP and Win7 operating systems.

Did you have any further success installing vb6. How did you compile the dll you mentioned?

Don

---

Donald R. Padgett

Answer 55

Brian, Can you tell me how to over come installation problems with vb6. I still can not compile anything on windows 8 using vb6. Help Please, Don

---

Donald R. Padgett

Answer 56

Don, which version of the Win 8 preview are you using? I used the 32-bit version w/o the dev tools pre-installed. I don't remember if there were any special steps, but I have a virtual machine where I could repeat it if needed.

Answer 57

don,

you need to select the setup and set the compatability mode. then you can compile any dll or exe

pieter

Answer 58

We are waiting for the Win7 SP1 Fix. Thanks in Advance.

---

L.A.G.M.

Answer 59

Anyone know if there is any more progress on this yet?

M.

Answer 60

Anyone know if there is any more progress on this yet?

There hasn't been any progress on getting a fix in a year. 

If you can render the original thread you will see that the problem was reported in the SP1 beta but Microsoft released it anyway.  Now, a year later, the only official thing that Microsoft has said that fixes the problem is to go to Windows 8.

So Microsoft spent the year fixing it in their next operating system but not in their current one -- the one that is supposed to be fully supported.

---

http://www.saberman.com

Answer 61

Announcement:

We have just published the fix for Win7 SP1 and Win Server 2008 R2 SP1. Please download and install the KB from http://support.microsoft.com/kb/2640696 (also, please read the section "Update Information" carefully). This fix is very similar to the Win8's fix; so if you can work well with the Win8 fix, it is very likely that the new fix can work for you as well.

In case if you encounter any issues with the new fix, please post the detail steps to reproduce the issue in the forum. Or if it is an urgent issue blocking your business, please file a new request to our customer support team.

Thanks,
Ming.
WDAC Team, Microsoft.

 

Answer 62

Thank you for fix.

I've tested it compiling with Windows 7 SP1 Spanish version and using it in Windows XP SP3 and Windows 2003 Server for the moment all works ok. Also Jet Replication Object works.

Waiting for that fix for almost 1 year.

Answer 63

I have tested both the 32-bit and 64-bit hotfixes with the ADO test program I wrote 10 months ago, and handles and memory are no longer leaked  when using async EXEC.

Thank you Ming, I guess you had a long internal battle to get the hotfix released.

Angus

---

Angus Robertson - Magenta Systems Ltd

Answer 64

This works!

Thanks for the fix! In the future a little soooner? :-)

p_sie

Answer 65

Hi Ming,

Does this problem effects DAO objects as well ?

because I am facing an issue with DAO objects, and related question I have posted @ My Question  and an blog post similar is yahoo blog.

Please help 

Answer 66

Psaradhi,

No, the fix shouldn't be related to the DAO issue.

If you suspect that this is an Access 2010 problem, you can try to post your questions on: http://social.msdn.microsoft.com/Forums/en-US/accessdev/threads, where there are more professional Access developers.

But from your Yahoo blog post,

         "Even I tried of installing Access 2003 in Windows 7 and run the MDB, still I didn't get any performance improvements"

If I haven't misunderstood the above sentence, this doesn't sound like to be an issue about Access 2010, since you got the similar behavior with Access 2003 on Win7. So, the remaining question is whether there are any problem on Win7, the Sybase ODBC driver, or the Sybase backend.

I would recommend you to change *one* component at a time. If we have proved that it is not related to Office 2010, you can then try to install the Office 2010 on Vista / XP to test whether it may be an issue in Win7 (please use the same version of Sybase ODBC driver and the same Sybase server).

btw, According to my ODBC experience, the "timeout expired" error for SQLExecDirect is usually related to the backend server, but not related to the client side (i.e. Access) - the client simply submitted a query to server and the server didn't responsed in time. You can try to increase the timeout value via the "ODBC Query Timeout" statement attribute (SQL_ATTR_QUERY_TIMEOUT). But I am not sure how this can be done from a DAO project. Again, try to post your questions on "Access for Developer" to see whether there are some DAO experts there.

Anyway, this DAO issue is not related to the current fix. So, please don't reply this message anymore for this issue, or you will "pollute" this forum thread.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 67

I am happy to hear about this fix for so many out there who needed it on Windows 7 SP1, but since the fix was not sooner, we ended up installing the Oracle client with the ODBC drivers and using this instead of the Microsoft ODBC drivers so that our existing Kofax SoftBridge Basic Language scripts could connect to our Oracle database after being compiled under Windows 7 SP1.

Thanks,  Catherine

Answer 68

We tried the patch (KB2640696) and, unfortunately, had to roll it back. The patch causes MS Access applications, which worked fine on W7 SP1 as well as older OSes, to fail. I’ve traced the problem and (after a few hours) was able to prepare a minimal working example that reproduces the issue.

You can download the example file here (www.moware.at/Download/Win7SP1ADO-Patch-Bug-Repro.zip) or create it yourself using the following steps:

1. On a Windows XP SP3 machine with Access 2007 (Windows XP mode works fine for this), create a new database (repro.accdb).
2. Create a new form (Form1) and add a Text Box (Text0) and a Button (Command2).
3. In the Text Box, enter =myFunction() (including the “=”) as the Control Source.
4. On the Button, select [Event Procedure] as the On Click event handler.
5. In the code window for the Form, add a reference to “Microsoft ActiveX Data Objects 2.8 Library” and enter the following code:
   

Option Compare Database
Option Explicit

Private WithEvents unusedAdoObject As ADODB.Connection

Function myFunction()
    myFunction = "x"
End Function

Private Sub Command2_Click()
    MsgBox Text0.Value
End Sub

6. Compile the Database into an ACCDE (repro.accde).

Now switch to some other PC and open repro.accde with Access 2007 or 2010 (be sure to use the accde file, not the accdb one!). Open Form1. You will note the following:

• Old OS (Win XP): Text0 shows “x” and Command2 shows a message box with “x”.
• Windows 7 SP1: same as Old OS.
• Windows 7 SP1 with KB2640696 Patch: Text0 shows “#Name?” and Command2 results in an error message about an “invalid use of the . or ! operator”.

So, after installing the patch you might no longer be able to run apps which worked fine before.

Answer 69

Heinzi,

Thanks for telling us about this issue. We can reproduce the issue on our side. We will investigate what's the root cause. Please stay tune.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 70

Heinzi,

Compare the setting of SandBoxMode in the registry.
Your configurations contain different values ​​for this parameter.
My opinion is:
Calling a function from an event handler is unsafe expression and must be rewritten.
Your error is not related to the ADO.

Sincerely,
Pavel Fursov

Answer 71

Pavel,

> Compare the setting of SandBoxMode in the registry.Your configurations contain different values ​​for this parameter.

No, they don't. The only thing that differs in the configuration is whether the patch is installed or not.

> My opinion is: Calling a function from an event handler is unsafe expression and must be rewritten.

Sorry, but this does not make sense at all. Using VBA expressions in the Control Source is a perfectly valid and officially supported feature of Access.

> Your error is not related to the ADO.

Of course it is: The problem only occurs if the ADO patch is installed AND the "Private WithEvents ... As ADODB.Connection" line is present in the code.

Best regards,
    Heinzi

Answer 72

Heinzi,

I am sorry. Initially I did not investigate the matter in full and somehow decided that the reason was the event.
I ran your example on my system with Windows 7 SP1 Office 2010.
I got a value #Name in the textbox and an error by clicking a button.

I did an experiment. Your function myFunction I put in the new module. Then compile under Windows XP SP3.
When running on Windows 7 SP1 with KB2640696 everything was fine.

Still I tend to the problem of unsafe expressions. In the class forms such functions are not safe, but they are safe in the module.

Sincerely,
Pavel Fursov

Answer 73

Hi Pavel,

Thanks for looking at this issue. To reject your theory about "functions in class forms" being the reason for this issue, I have prepared an example that reproduces this problem while myFunction resides in a module:

1. Prepare the database, Text0 and Command2 as described above (Steps 1-4 of my previous post).
2. In the code window for the Form, add a reference to “Microsoft ActiveX Data Objects 2.8 Library” and enter the following code:

Option Compare Database
Option Explicit

Private c As Class1

Private Sub Command2_Click()
    MsgBox Text0.Value
End Sub

3. Add a new module Module1 with the following code:

Option Compare Database
Option Explicit

Private c As Class1

Function myFunction()
    myFunction = "x"
End Function

4. Add a new class module Class1 with the following code:

Option Compare Database
Option Explicit

Private WithEvents unusedAdoObject As ADODB.Connect

5. Compile the Database into an ACCDE and test on various systems. Same result as before.

This seems to be a very tricky issue inside the Access compiler: Remove "Private c As Class1" from either Form1 or Module1, and the problem vanishes. So, Pavel, I do appreciate your input, but I really don't think that we (= Access users) can solve this issue. It has to be tackled by people with access to the MS Access source code.

Best regards,
    Heinzi

Answer 74

Hi All,

Like others, I've been waiting more that a year for this fix.  I hesitated to immediately install the fix in order to see if it creates any other problems for developers.   However, it's been pretty quiet out here (on this forum) for the last 5 days.  Yes a few positive comments, but I thought I'd see many, many more.

Therefore, if you've installed the fix with success, or failure, us laggards (that can't afford the time to install, and then back it out), would love to hear from you.

Regards,

-Jeff.

---

Jeff Gordon - Gorodetsky Inc - Working at Cisco Systems

Answer 75

To avoid more discussions on whether it is a supported usage, I would like to update this thread with what we have right now. There might be some more update in the future, when we know more about the issue.

                  Sorry, we confirmed that this issue is resulted from the latest patch (KB #2640696).

The root cause is that some interface definitions in the typelib (msado28.tlb) were re-ordered, although all interface definitions were restored to what it looked like in Vista. It seems that the ACCDE project has somehow stored the ordinal (or something equilvalent) of an interface definition in the typelib, it won't work after the ordering of interface definitions changed.

As an experiment, we have tried to recover the ordering and it works afterward.

As a side note, we found some similar issues:

• If you compile your ACCDE (referencing ADO 2.8 typelib) on Win7 SP1 (with KB #2640696), you can't open it on XP. (The opposite way)
• It doesn't work even if you reference the other versions of ADO typelibs on Win7 SP1 (with KB #2640696).
• The same issue should also occur in the Win8 Developer Preview Build
• If you compile your ACCDE project referencing 6.0 typelib on Vista, you will get a similar issue if you open it on Win7 SP1.

We are currently studying the impact of this issue is. Up to now, what we understand is that this can impact a compiled ACCDE projects (or some other compiled Access projects) using ADO events. As what Heinzi reported, a corresponding ACCDB project was not impacted. Also, a simple ACCDE project using ADO but not using ADO events have no issue as well. We are talking to the VBA team to better understand the impact. In case if you found any other issues with the package (that is not falling in the above areas), please let us know immediately. It is important for us to have your help to find all other issues.

After we understand this issue better, we will determine what we can do in the next step.

Again, if you find any issues that is not related to (ADO event + ACCDE/MDE projects), let us know immediately.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 76

"Any other issues"

Here is an issue:

After applying the SP1 and the KB #2640696 "fix"

in an unmanaged c++ solution using the following #import statements in stdafx.h:

//#import <msado15.dll> rename("EOF", "adoEOF")

#import <msado60.tlb> rename("EOF", "adoEOF")
#import <msadox.dll> no_namespace rename("DataTypeEnum", "adoxDataTypeEnum")  <- this statement is not needed to break the compile.
#import <msjro.dll>  no_namespace rename("ReplicaTypeEnum", "jroReplicaTypeEnum")

msjro.tlh and msjro.tli files will be autogenerated.

the compiler errors on the autogenerated files when trying to resolve a type _RecordsetPtr

i.e.

msjro.tlh(196): error C2146: syntax error : missing ';' before identifier 'ConflictTables'

The following is the code that is causing the error:

    __declspec(property(get=GetConflictTables))
    _RecordsetPtr ConflictTables;

Answer 77

Heinzi,

Could you comment a little bit about the feasibility to workaround the issue by separating the ADO object into a new class module? Is it possible in your work environment to use this workaround?

In case if it is possible, everything would be fine.

Otherwise, you may need to contact our Customer support team to officially open a case to track the issue, and state your business impact on this issue.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 78

Since MSJRO is a really old component, we have pointed it to the ADO 2.8 typelib.

Therefore, please update your program as follows:

#import <msado28.tlb> rename("EOF", "adoEOF")
#import <msadox.dll> no_namespace rename("DataTypeEnum", "adoxDataTypeEnum")
#import <msjro.dll>  no_namespace rename("ReplicaTypeEnum", "jroReplicaTypeEnum") </msjro.dll></msadox.dll></msado28.tlb>

In other words, change the line "msado60.tlb" into "msado28.tlb". Please make sure you manually delete the intermediate file: msjro.tlh. It seems to me that Visual Studio does not automatically delete the file even if you click "Rebuild All" whenever it found the file exists.

Could you confirm whether this works for your scenario?

Also, could you help us to test the recompilation scenario? Namely:

(1) Compile your old application on an old OS (e.g. XP), and run in on the patched Win7 SP1.

(2) Recompile your application on the patched Win7 SP1 (with the above code changes), and run in on an old OS (e.g. XP).

Thanks,
Ming.
WDAC Team, Microsoft.

Answer 79

Pavel,

Unfortunately, putting the ADO object in a new class module does not solve the problem. Please have a look at the second repro example that I posted in reply to Pavel: The ADO object is only present in Class1, not in Form1. Form1 just contains a reference to Class1.

In fact, using one of our larger business applications, I can reproduce the issue even with Form1 having *no direct reference* to Class1, but just an indirect one (Form1 code contains a method call to some method of Module1, and Module1 contains a reference to Class1). However, I currently don't have a minimal working example for this. If required, I can try to create one, but I'll only do it if someone specifically asks for it, since it's a lot of work (take huge application; remove some code, compile on XP, copy to W7SP1FIX test machine, test; repeat until the example is minimal).

So, at the moment, I'm not aware of any usable workaround (except for not using ADO events). Please tell me if you want me to prepare a minimal sample for the situation described above.

Best regards,
Heinzi

Answer 80

Pak,

Using the msado28.tlb does allow the code to compile. 

The original guidance after applying the patch is that msado15.dll imports are to be replaced with msado60.tlb.  Is it equivalent to use the msado28.tlb?  I am not familiar enough with ADO to know.  I am assuming that I should only use msado28 in places where there I need to use the MSJRO library.  You mention that MSJRO is old.  Is there something that we could use in its place?

About the testing:

I don't have the time to test #1.

I will be testing the second scenario but it will take a while.

Answer 81

Heinzi,

I don't think that you need to work out a more complicated repro to prove the issue. Actually, your previous simplified repro is a very good one, and we can identify the problem quickly.

Internally, we are discussing how to handle this issue.

Since this is a new issue in the fix, I think that you can open a new case with our customer support team. This allows us to track the issue and we can also study your business impact. After that, we can investigate whether there is a better workaround, or investigate the feasibility of providing a new fix. 

Sorry about that there is a new issue in the fix.
Again, thanks for telling us about this issue.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 82

Yes, msado28.tlb is essentially the same as msado60.tlb. You can change the reference into msado28.tlb without any loss in functionalities.

Yes, JRO is already deprecated (see our roadmap). Unfortunately, there is currently no replacement that can cover all functionalities of JRO. But if you can tell us what functionalities you are using, we may be able to provide a replacement.

Again, thanks for helping us to test the patch.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 83

Ming,

Thanks for your answer. We have also discussed this issue internally and, in the end, decided that it's possible for us to get rid of the code parts that require ADO events in the next version of our software. Thus, this issue is no longer a problem for us.

Thanks for your support,
Heinzi

Answer 84

Heinzi,

That's a good news. Thanks for telling us. :-)

Please reply to this thread, in case if you find any other issues about the package.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 85

Hi Jeff,

We have found that the fix for SP1 works for us just like the Win 8 version did. To recap our issue: we have a VB6 class library that has some public methods that return ADO recordsets. This library is set up with binary compatibility. When trying to recompile on a Win 7 SP1 system, VB6 complains that the methods returning the recordsets are no longer binarily compatible. With the fix, there was no such problem.

Brian

Answer 86

Thanks for this, Ming.  Might be a dumb question, but do I need to download x86 fix, the x64 fix, or both?  The project I'm working on involves compiling VB6 apps with the VB6 IDE,  and .NET DLLs built with VS 2005 on a 64-bit Win 7 machine.  I suspect I only need the x86 fix, but want to be sure.  I've already backed out  Win 7 SP1 once and don't want to screw things up and have to do it again.

Thanks.

Steve

Answer 87

Steve,

In my own experience, I am running Win 7 64-bit, and I applied the 64-bit fix, even though I'm using a 32-bit IDE (VB6) and compiling 32-bit apps. I didn't need to install the 32-bit fix. So I think you only need one or the other.

Of course, I'm sure Ming will give the official word.

Brian

Answer 88

Pak-Ming,

I have the following problem using the new 6.0 Library to compile older code.

 

The new module provided in Windows8 for ADOR type com objects compatibility is the 6.0 library (msador15.dll). This new module has fixed some of our com objects. However, when trying to compile client side objects  with this same 6.0 module, there is one byRef argument type mismatch compile error that I can not overcome. It is  on any call that uses the following array of recordsets as an  argument in the call. Here is the dim statement and use of the rsGroup variable: 

Dim rsGroup() As ADOR.Recordset.   

Set sbo = ClientMod.Createobject(m_identity, m_progid)
IB_Security_addGroup = sbo.addGroup(m_identity.serialize(), rsGroup())
Set sbo = Nothing

  Below is the interface library that contains the signature for the Call:

    interface IB_Security : IDispatch {

        [id(0x60030001)]

        HRESULT addGroup(

                        [in, out] BSTR *Identity,

                        [in, out] SAFEARRAY(_Recordset*)* group,

                        [out, retval] long* rc);

---

Donald R. Padgett

Answer 89

Hi Brian,

Thanks for the info.  The silence on the forum after the fix was released confused me.  I didn't know if the fix was so perfect that everyone installed it and then unsubscribed from this forum or, if the fix has been so long in coming that everyone just gave up on ever getting one.

Unless anyone warns against it now, I'll try installing SP1 (then the fix) and see if I (too) can unsubcribe from this forum. :)

Cheers,

-Jeff.

---

Jeff Gordon - Gorodetsky Inc - Working at Cisco Systems

Answer 90

Steve / Brian,

Brian is correct. For 64-bit windows platforms, you only need to install the 64-bit package, which contains the 64-bit native binaries and 32-bit WOW64 binaries. Since your development environment (e.g. VB6) is 32-bit, it will use your 32-bit WOW64 binaries.

btw, Steve, if you haven't yet installed the SP1, you can optionally choose to install the KB at: http://support.microsoft.com/kb/983246. This is the corresponding fix for Win7 RTM and downlevel platforms (including XP) for the Office 64-bit interoperability issue. But the content of the fix is essentially the same as the Win7 SP1 fix. Of course, it will also work if you choose to install the SP1 and then install the KB 2640696. Of course, we generally suggest customers to install the latest SP so that your system is the most secure and fastest. So, installing 983246 is just an simple option for you to test your scenario. After testing, you are still recommended to install SP1 + 2640696.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 91

Donald,

There is insufficient information for me to understand what happened in your case. Could you help to give more information?

In general, for a client / server application, you may need to recompile both of your client and server to let it work. If you have only compiled one of them but not the other, it may not work properly especially if one of them have been recompiled under the unpatched Win7 SP1.

If the above suggestion does not help, could you give me more information say:

- What version of windows OS are you using (both client / server)? Also, are you using 64-bit windows or 32-bit windows?

- Is your COM server runs on the same machine as your COM client?

- What's the programming language to build the components? From your description, are you using C++ to develop the COM server and the VB6 to develop the COM client?

- Are you compiling a 64-bit application when you are using C++? Please note that 6.0 typelib does not support platform interoperability since it used an ADO_LONGPTR, which is of different length on different platforms.

- You said that you have used the AdoR typelib. Have you tried to use ADO 6.0 typelib? The ADOR is just a subset of the ADO typelib.

- Does your application works before (on which platform?)?

- Could you simplify your application and demostrate your issue (better to include a piece of code snipplet)?

If this issue blocks your business, please contact our customer support team directly.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 92

Ming (and Brian),

OK, I understand I need just the 64-bit package.

After I've finished work my current project, I'll install SP1 and 2640696 and verify everything works.

Thanks.

Steve

Answer 93

Ming,

Thank you. I am working through using the ADO typelib. Will let you know the results

Don

---

Donald R. Padgett

Answer 94

Ming,

Using VB6 in Win8 (with 6.1 lib and msador28.tlb) to recompile our com objects. This works in Win7(sp1)/Win8 with a few changes to use ADO references.

However, When i compile using the 6.0 lib and msado28.tlb to gain down level compatibility I am faced with a Compile Error:
   -Compile error: ByRef argument type mismatch
   -this happens any where we are using an array of ADOR.Recordset variable:    MyArray() As ADOR.Recordset

You ask for us for issues with this new fix. This error seems to be the only thing standing in our way.

Thank you,

Don

---

Donald R. Padgett

Answer 95

Sorry for late response, since I am just back from my vacation.

If you can use the msadoR28.tlb, your program will already be backward compatible to downlevel system (e.g. XP, Srv03, etc.).

But I agree that it is still a problem if it doesn't work with 6.0 or 2.8 typelib. So, have you followed the ideas on my last post to isolate the problem. For example, recompile all client / server pieces after deploying the new patch.

Could you give me more information as requested in my last post, so that I can study the problem in my local environment?

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 96

Don,

Are there any update on your issue? Could you provide us with more information about the issue? Without more information, we cannot proceed your case anymore.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 97

Hello,

I installed the KB2640696 fix and it replaced my 6.0 library to 6.1 library. after compiling and running in other win 7 workstations it still gives the same runtime error 430 "class does not support Automation ...." but along with that it also affected all my DAO references as well. 

now along with error 430 all my DAO references have stopped working.

to get the 6.0 library back i uninstalled the patch and that removed 6.1 but couldnt get 6.0 back so now i am big time screwed.

Please guide me to how to fix this thing.

Zooon

Answer 98

Zooon,

A few questions:

- Where did your program compiled before?

- Did your program works for Win7 RTM (not SP1) and Vista / XP before?

- If there are multiple components involved, all of those components have to be recompiled with the patched machine. If some component is compiled under Win7 SP1 and some component is compiled under the patched machine, these components may probably not work together.

- Could you provide a simplified code to reproduce the issue? There is not sufficient information to troubleshoot the problem right now.

- If the issue is urgent to your business, please contact our customer support team and they can help you to setup the repro program.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 99

Thanks for the fix.

I'd like to inform that after the first tests, Applications Compiled with VB6 in Windows 7 SP1 are working well in older Windows (W2K, WinXP and Win 2003 Server) after installing the fix. Did not believe at the first time, but after the tests, no more problems.

Thanks again for the efforts you have made.

Luiz Alfredo G. Menezes

Newdata Informática

Brasil

 

---

L.A.G.M.

Answer 100

Watchers of this thread may be interested to know Windows Update KB2698365 has broken ADO, but perhaps in a less deliberate fashion.  The msado<nn>.tlb files don't match msado15.dll after applying this update.  See this thread for details:

    http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/b9e6c83f-76f0-447f-ba17-22a43b0bbac2/

And this thread for the sort of problems it causes:

    http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/74957f74-3d28-41f6-b039-9fdd84fe48f3

Phil

[Thanks Sheng Jiang for pointing me to this thread]

---

Phil Penney

Answer 101

Just as a FYI.

After released the Design change (DCR) fix (KB #2640696) for about 5 months, we found that most customers are satisfied with the DCR fix. Although there are still some minor issues about the need to change the typelib reference during recompilation, most customers can get the DCR fix work. 

Also, there was a security issue found in ADO component. Given that the quality of the DCR fix should be roughly ok and the "internal" code base branching design, we shipped the entire DCR fix to all customers via the security fix (KB # 2698365) recently [Windows Update will ask you to install the security fix, rather than requiring customers to download the fix from our support website].  

The fix in the security patch included everything inside the DCR fix (KB #2640696). But it also fixed an issue about a change in interface ordering (as reported by Heinzi.at in this forum thread). Basically, we reverted back to the original interfaces ordering as in Win7 RTM. 

Unfortunately, we found that the latest security fix can still break some RDS applications (http://social.technet.microsoft.com/Forums/en-US/w7itprosecurity/thread/74957f74-3d28-41f6-b039-9fdd84fe48f3). Our support team is working on this fix right now. 

The issue reported by Phil (http://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/b9e6c83f-76f0-447f-ba17-22a43b0bbac2)  is actually kind of "by-design". He/She has to reference a downlevel typelib in his/her legacy project.

This is just a FYI to this forum thread. To avoid making this forum thread unmanageablely long, I will reply to those two forum threads directly for those two issues. 

Thanks,

Ming.

WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 102

Pak-Ming  & other Respected Community Members,

             I have one VB6 COM+ application installed on Windows server 2008 which has reference to one tlb file and uses its methods.

 When i run the client application from remote PC and call this COM+ compoennt installed on WindowsServer 2008, it throws an error:-

err.description:-   "Automation Error"

err.number = "-2146233079"

I have TSSClassLibrary.tlb referenced in the COM+ object and this error comes in the 2nd below step in it:-

Dim cTSS As TSSClassLibrary.TSSInterface
Set cTSS = New TSSClassLibrary.TSSClass

If i install that COM+ object in windows server 2003..it just work fine...without any issues.

Does any one have any idea whether this is issue more with windows server 2008 or something else??

Thanks,

Nick

Answer 103

Nick,

This may be a totally different issue. We haven't changed any ADO interfaces on Windows Server 2008 (or Windows Vista), unless you downloaded and installed the QFE yourself [KB #983246]. This is the same, even if you installed the latest security patch (KB # 2698365). In other words, if you have installed KB #983246 and KB #2698365 together, you get the new sets of ADO interfaces; if you have only installed KB #2698365, you are still using the old set of ADO interfaces.

This is very different from Windows Server 2008 R2 (or Windows 7), where we pushed the change into SP1. So, you get some interface changes in the KB #2698365 (without installing any KB yourself) in these two platforms.

Therefore, please double-check your Windows Update history to see whether you have installed the KB #983246 yourself.

===============================================

btw, For the issue you are seeing, you may want to double-check whether this is related to any patch installed. Did it worked before? Do you see this issue recently? Have you changed any code recently? Are there any special in the typelib "TSSClassLibrary.tlb"? Does it referenced any ADO interfaces?

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 104

Pak-Ming,

              Thanks for the detailed update. But this is something i am trying to develop the model first time as part of our new Host integration server 2010 migration and i wants to keep the same COM+ functionality expect introducing this TSSClassLibrary.tlb which is VB.NET Wrapper class.

I created this vb.net wrapper class because I need to consume WCF service and one of the microsoft representative guided me to introduce vb.net wrapper class as there is no easy way to consume WCF service directly into vb6 application.

TSSClassLibrary.tlb file is created by using regasm.exe command on TSSClassLibrary.dll file. SO on the WIndows server 2008, i have COM+ component which calls this tlb file using below statements:-

Dim cTSS As TSSClassLibrary.TSSInterface
Set cTSS = New TSSClassLibrary.TSSClass

and that's where the Automation error comes. but i think this is not ADO error ....am i right???

Thanks,

Nick

Answer 105

Nick,

Thanks for your update that this is not an ADO issue.

So, it seems to me that this is not appropriate to talk about this issue in this forum thread anymore. For your problem, you may consult the MS representative you mentioned and I believe they may help you. Or, you may start a new forum thread so that relevant people (inside / outside Microsoft) can help you accordingly.

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 106

I'm getting something very similar on Windows Server 2008.

Trying to run a VB6 app that uses msado27.tlb, but as soon as I run the line "set dbCnct = New ADODB.Connection" it throws an automation error ("The specified module could not be found").

I can confirm that c:\program files (x86)\common files\systems\ado\msado27.tlb and is freshly registered with regtlibv12.

This file is 80k and dated 08/Nov/2010.

Might this be related to this thread? If not, where should I post?

BTW - I've been told to avoid SP1 - is this good advice? Cna't be any worse, surely?! ;-)

******

UPDATE

******

I did apply all updates and the problem is fixed. Apologies for any waste of time.

Answer 107

They did it again:

last night microsoft update damaged MSCOMCTL.OCX  <<== This is a Microsoft Forum Thread

---

http://www.saberman.com

Answer 108

Yep.  Change to MSCOMCTL.OCX was part of the August 14th Patch Tuesday.  Phones have been ringing off the hook with customers down due to this issue. 

I cannot just re-compile 500+ customized application that use the control.  Reverting back to a version that does not break my app is the only short term fix.

Darren

Answer 109

The link is to a thread in Access for Developers (MS Forum)

---

http://www.saberman.com

Answer 110

The problem with MSCOMCTL.OCX is worse than the ADO problem.  At least with the ADO problem if you built on a downlevel machine it would run on a machine with SP1.  In the case of the MSCOMCTL.OCX problem a compiled app will only run if the machine has the same level OCX as the one it was built on.  So you cannot create a build that will work on both machines that have the new version and machines that have the old version.

So if you revert your customers to the old version of the OCX it will break any other venders product built with the new version of the OCX.

---

http://www.saberman.com

Answer 111

Saberman,

Sorry, but this thread is dedicated to discuss the ADO issue. I would like to make sure customers can obtain the related information easier from this thread.
For the issue in mscomctl.ocx, there is already a forum thread opened. And that thread should be the best place to discuss that issue. 

Thanks,
Ming.
WDAC Team, Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 112

Your are correct about the discussion – it belongs in the other thread.  However, my first post about this -- with the link to the other thread -- is appropriate as it provides important information about how much Microsoft is concerned about what happened in the ADO debacle and how much Microsoft will apply (or in this case not apply) the lessons learned .  It provides important information about how much the vendors affected by the ADO debacle can rely on Microsoft’s concern about them in the future.

---

http://www.saberman.com

Answer 113

Confirmed what  Ming said: Read "More Information" (name changed from "Update Information"). It is crucial information.

Our problem was solved by applying KB2640696, plus the one-line code change mentioned in the "More Information" section. (C++ user here).

+sean

Sean Medina

Answer 114

This is a very very large thread, so I can't see the solution.

I've found this issue when I updated W7 to SP1 a lon time ago, so I changed the production machine to an older Xp.

Now I've changed my computer to a W 8.1 x64. I've recompiled my 32 bits C++ application with Visual Studio 2010, and ... the progran doesn't work in XP or Vista or W7 RTM!!!

Note 1: I use 

#import <msado15.dll> rename("EOF", "EndOfFile")
using namespace ADODB;
#import <MSJRO.DLL> no_namespace rename("ReplicaTypeEnum", "_ReplicaTypeEnum") 

Note 2: I must support my Windows XP customers computers, so I must use

#define _WIN32_WINNT _WIN32_WINNT_WINXP

---

Luis González Torquemada

Answer 115

Luis,

As mentioned in the first post of this thread, you can try to import the 2.x typelib, since you still need to support the downlevel platform - WinXP. The typelib embedded inside msado15.dll is of version 6.1, which should only be used when you don't need to support downlevel platforms.

In other words, you can try to change the line from:
            #import <msado15.dll> rename("EOF", "EndOfFile")
to
            #import <msado28.tlb> rename("EOF", "EndOfFile")

Please have a try.

[btw, I have already moved on to a different team within Microsoft. Therefore, this is not the official answer from the Microsoft WDAC team. If this does not work, you should search online and/or you should talk to someone else who has similar requirements in this forum]

Thanks,

Ming.

Bing Team - Microsoft.

---

Pak-Ming Cheung - MSFT

Answer 116

Thanks! It Works fine... ...but I've used msado27.tlb, because msado28.tlb is not present in Windows XP.

---

Luis González Torquemada