none
Breaking change in MDAC ADODB COM components in Windows 7 Service Pack 1 (repost with MSDN liveID)

    Question

  • As my MSDN subscription is connected to this liveID, I repost my question in the hope to get a faster answer:

    After I installed Service Pack 1 on my Windows 7 x64 Ultimate my applications which use MDAC 2.8 COM components for database access do not work on other Windows versions any more.

    I hunted this down to changed Interface IDs in the msadoxx.tlb files. On Windows 2008 R2 e.g. the IID of dispinterface _Connection is {00000550-0000-0010-8000-00AA006D2EA4} (defined in msdado28.tlb). When I lookup the same dispinterface on my Windows 7 with SP1 (RTM from MSDN) I see this IID {00001550-0000-0010-8000-00AA006D2EA4}.

    That means that all code produced on Windows 7 SP1 using ADODB cannot be run on any other version of Windows as the IIDs differ.

    The CLSIDs still match, so the COM objects get created but due to different IIDs they cannot be used.

    I really hope I am missing something as this change seems to be a massively breaking change in the MDAC API.

    To verify the error you can use code like this in VB6 or equivalent in VB.Net or C# and compile it on Win7 SP1 and run it on Win7 RTM or older versions of Windows:

    Dim cn As ADODB.Connection
    
    Dim o As Object
    Set o = CreateObject("ADODB.Connection") ' this does still work
    
    Set cn = o ' this errors when compiled on Win 7 SP1 and run on older versions of Windows due to the changed IID of the dispinterface _Connection
    

    Regards,
    SvenC

    Friday, February 18, 2011 10:12 AM

Answers

  • Yes, EinmalIM is right. 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.

    - 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)

    - 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.

    [Important Note: Since this thread become very long and it is ineffective to do more communication on this thread, I have opened a new forum thread at: http://social.msdn.microsoft.com/Forums/en-NZ/windowsgeneraldevelopmentissues/thread/280de88a-77dd-455e-9797-b28928206e38. Please reply or discuss on the new forum thread instead of this one. This can save everyone time and effort to browse through your new findings and discussion. We will not monitor this forum thread anymore, but monitor the new forum thread].

    =========

    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
    Monday, September 19, 2011 3:01 AM

All replies

  • I think you hit an issue described in http://support.microsoft.com/kb/983246. Could you please check if using the approach in that KB article can solve your problem? Thanks.
    Saturday, February 19, 2011 1:21 AM
  • Here is the kb for the QFE: http://support.microsoft.com/kb/983246

    There is one section in the kb talk about this issue:

    Important After you install this hotfix on a computer, some applications that run correctly on the computer may not run correctly on other computers.
    there are 2 workaround

    1.   Install the Typelib QFE package on down level OSes in the above KB.

    2. always using late binding:Dim o As Object.

     

    Saturday, February 19, 2011 4:30 AM
  • Here is the kb for the QFE: http://support.microsoft.com/kb/983246

    There is one section in the kb talk about this issue:

    Important After you install this hotfix on a computer, some applications that run correctly on the computer may not run correctly on other computers.
    there are 2 workaround

    1.   Install the Typelib QFE package on down level OSes in the above KB.

    2. always using late binding:Dim o As Object.

     

     

     

    I checked the KB article, and this is not an issue of x86 and x64. The changed IIDs are new to SP1 of Win7 / 2008 R2.

    I know that late binding with IDispatch or Object would work, but that does not help with existing code.
    And as MDAC is a Microsoft component it will not only affect our code but everybody using MDAC

    Please compare the IID of dispinterface _Connection in Windows 7 SP1 and any older version of Windows yourself and see that it changed. Check other dispinterfaces and interfaces as well and see they changed as well.
    That change breaks COM compatibility of ADODB interfaces which I consider a serious bug in SP1.

    Please escalate this issue because of the reach of breaking code.


    -- SvenC
    Saturday, February 19, 2011 10:20 AM
  • I can confirm there is a major problem with Windows 7 SP1 (x86 or x64) and VB6 and ADODB.

    I have double confirmed this by removing and replacing SP1 on two PC's and the problem definitely does occur after SP1 is installed.

    The variation I see it that all our VB6 projects won't compile if they use ADODB Data Controls.  The error message implies that the code for the parameters on the event on a Data Control MoveComplete is incorrect.  I tried to remove the code and allow the empty event to be recreated so that I can put code into it.  However when I tried this the ADO Data Control would not produce an empty event for Move Complete for me to use and just errored.

    I am just restoring all our PC’s to pre SP1 which does cure the problem, and will give the exact error messages for you shortly.

    I tried the patch suggested by Leo, but it did not work.

    I have also tried not upgrading to WIN7 SP1, but building a fresh PC with a Win 7 SP1 DVD., but still got the same problem.

    This bug means that all VB 6 projects using ADODB won't work with Windows 7 SP1 (x86 or x64) and is a very serious problem for all VB6 developers.

    I also request that this issue be escalated because of it's serious nature.

     

    Saturday, February 19, 2011 11:43 AM
  • Just to make this clear: this is not a VB6 only issue.

    Any programming language using MDAC COM classes with more specific interfaces than IDispatch will break due to the changed IIDs.


    -- SvenC
    Saturday, February 19, 2011 11:50 AM
  • Further to my comment above.

    The error message given on the ADODC Data control is ...

       " Procedure declaration does not match description of event or procedure having the same name "

    if you delete the offending code (which is perfect and should not cause any problem) and you try to create a new blank event by clicking on the MoveComplete you get the error message ...

      " User-defined type not defined "

    I believe EinmalIM may have a better technical description of the problem, I can only give you the error message displayed in VB6 with ADODB and Windows 7 SP1.

    I hope this help you isolate the problem quickly.

     

    Saturday, February 19, 2011 7:33 PM
  • It looks like the break is intentional, when opening the Program files\Common Files\System\Ado\msado15.dll file in OleView, you would see old interfaces are renamed to have a _deprecated postfix like  _Connection_Deprecated . I guess the user's computer needs to install an MDAC update that has yet to be released for platforms other than Windows 7.

    The latest updates involving MDAC I can find is

    Microsoft Security Bulletin MS11-002 - Critical Vulnerabilities in Microsoft Data Access Components Could Allow Remote Code Execution (2451910)

    And installing the security update does not change the ado file.



    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
    Sunday, February 20, 2011 1:50 AM
  • I see the xxx_deprecated interfaces as well.

    But then compiling with the "standard" ADODB types like Connection and Command produces executables that use IIDs which simply do not exist on older versions of Windows.

    I really see no sense in this. And why was this silently changed when it has such a wide impact on existing code?

    Please, can anybody from Microsoft comment on this breaking change and how to go along with it?


    -- SvenC
    Sunday, February 20, 2011 8:56 AM
  • There is a by design change in ADO in Windows 7 SP1 that interfaces have new GUIDs as mentioned above. The pattern is that most of all ADO interfaces (say Connection) have new GUIDs while the old GUIDs are assigned to interfaces named xxx_deprecated (say Connection_Deprecated). The reason of this change is mentioned in KB983246:

    "Some ADO APIs are platform dependent in ADO 2.7 and later versions. On 64-bit versions of Windows, these ADO APIs process arguments by using a 64-bit data type (such as the LONGLONG data type). However, applications that use these APIs still use the LONG data type. Therefore, you receive a "Type Mismatch" error message when you try to run the macro."

    The interfaces with new GUIDs (in Windows 7 SP1) don't have such issue.

    This change causes a break that if your application is re-compiled on Windows 7 SP1 and it uses early binding to ADO, it probably doesn't work on down-level OSes, such as Windows 7 RTM, Vista, etc. Please note that this break only happens when the application is re-compiled. Existing applications should run on Windows 7 SP1 without any problems.

    If you have to re-compile your application on SP1, there are several workarounds:

    1. Request a package of KB983246 and install it on your customers' machines. Re-compiled application should work after the package is installed.
    2. Re-write your application to use later binding to ADO, or use interfaces with name xxx_deprecated.
    3. Keep an old version of ADO typelib (i.e., msado28.tlb) (copy from Windows 7 RTM), then compile your application with the old typelib, instead of the one in your system.
    Hope these help.


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    • Proposed as answer by dJohnston Tuesday, August 02, 2011 10:26 PM
    Monday, February 21, 2011 5:29 AM
  • Further to my comment above.

    The error message given on the ADODC Data control is ...

       " Procedure declaration does not match description of event or procedure having the same name "

    if you delete the offending code (which is perfect and should not cause any problem) and you try to create a new blank event by clicking on the MoveComplete you get the error message ...

      " User-defined type not defined "

    I believe EinmalIM may have a better technical description of the problem, I can only give you the error message displayed in VB6 with ADODB and Windows 7 SP1.

    I hope this help you isolate the problem quickly.

     

    Hi Neil,

    I'd like to confirm that if you compile your application on Windows 7 RTM, it still work on SP1, is that correct?

    For the Data Control issue, it doesn't sound intentional, could you share a VB project that reproduces the issue? We'd like to investigate the root cause and fix it if necessary.

    Thanks,

    Shuhai


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Monday, February 21, 2011 5:34 AM
  • I think the breaking change needs to be documented in ADO SDK not in KB or a forum.

    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
    Monday, February 21, 2011 7:06 PM
  • I think the breaking change needs to be documented in ADO SDK not in KB or a forum.

    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
    Yes, we are planning to get this change into next release of Windows SDK. 
    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Tuesday, February 22, 2011 1:34 AM
  • Further to my comment above.

    The error message given on the ADODC Data control is ...

       " Procedure declaration does not match description of event or procedure having the same name "

    if you delete the offending code (which is perfect and should not cause any problem) and you try to create a new blank event by clicking on the MoveComplete you get the error message ...

      " User-defined type not defined "

    I believe EinmalIM may have a better technical description of the problem, I can only give you the error message displayed in VB6 with ADODB and Windows 7 SP1.

    I hope this help you isolate the problem quickly.

     

    Hi Neil,

    I'd like to confirm that if you compile your application on Windows 7 RTM, it still work on SP1, is that correct?

    For the Data Control issue, it doesn't sound intentional, could you share a VB project that reproduces the issue? We'd like to investigate the root cause and fix it if necessary.

    Thanks,

    Shuhai


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net

    If you compile the project on Win 7 RTM, it will run on Win7 SP1 RTM

    If you ty to compile on Win7 SP1 RTM (Upgraded or Fresh install) it won't compile.  End of story.

    How do I send you a sample project to see the problem, if I am able to make a simple one with the problem?

     

    Tuesday, February 22, 2011 11:52 AM
  • We have exactly the same problem with Windows 7 SP1. 

    It is only fixable by installing the KB983246 on every client computer that you put a compiled EXE on with SP1.

    I can't believe Microsoft have done this.

    One more thing, if you have any customers on Windows 2000 (we do, and I know, nothing we can do about it) they are stuffed.  There is no hotfix package for it and even trying to "force" the new dll's on from a Windows XP build with hotfix doesn't work. (msado15.dll etc)

    Looks like we have to tell ALL of our clients to patch their machines.  Great....

    Tuesday, February 22, 2011 12:12 PM
  • Hi Alan,

    while I find the decision of Microsoft in this case really, really bad as well, I would recommend to you to build against the old tlb file from pre-SP1. That works on any Windows version as Win7 SP1 still have the renamed xxx_deprecated interfaces with the old uuids.

    As I had troubles to get VB6 to use any other msado28.tlb instead of the registered one, I replaced the the system\ado folder contents with that from Win7 RTM and regsvr32'ed the dlls. With that "fix" even VB6 can build our code on Win7 SP1 again.

    Seems to me that all COM specialists either have slept, left or are too way up in the cloud.

    Oh Don Box, if they only had asked you if this change was a "COM-safe" change to the type lib...

    As if the Win SDK people would do something like #define CreateFileW CreateFileNewOnWinSP1W...


    -- SvenC
    Tuesday, February 22, 2011 12:25 PM
  • SvenC,

    I do tend to agree, but what with the TrustedInstallers issues on that directory it's a pain.

    And also, how long untill another update comes through Wiindows Update replacing them again without our knowledge.

    I've got over 30 dev machines here.  Big Pain...

    Tuesday, February 22, 2011 1:35 PM
  • Hi Alan,

    yeah, taking ownership and replacing ACLs to replace files is a bit time consuming if done manually on several machines...

    In the meantime I opened a support case with Microsoft. Let's see how that helps.
    But if solutions are given and those are not working on VB6 then we are out of luck as VB6 has run out of support.


    -- SvenC
    Tuesday, February 22, 2011 1:54 PM
  • If you compile the project on Win 7 RTM, it will run on Win7 SP1 RTM

    If you ty to compile on Win7 SP1 RTM (Upgraded or Fresh install) it won't compile.  End of story.

    How do I send you a sample project to see the problem, if I am able to make a simple one with the problem?

     

    Hi Neil,

    Could you please share the project by SkyDrive or other file sharing service?

    Thanks,

    Shuhai


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Tuesday, February 22, 2011 5:02 PM
  • I'm having this same problem with Visual Studio 2010 and MFC.  We use ADODB in 1 place in the code and now my code won't work on any computer not using Windows 7 SP1.

    Help!

    Tuesday, February 22, 2011 9:08 PM
  • I'm having this same problem with Visual Studio 2010 and MFC.  We use ADODB in 1 place in the code and now my code won't work on any computer not using Windows 7 SP1.

    Help!

    Hi Rene,

    I guess you use #import to generate the wrapper classes?

    Then you can copy an msado28.tlb from a pre SP1 machine into you project and import that version.
    Do not rely on importing by libid or progid which would find you the new IIDs of the system registered type lib on Win7 SP1.

    @Microsoft: I really question the way you went with that type library change.
    It disturbes quite some code relying on ADO and you didn't even care to document this in the release notes of SP1. Not good.


    -- SvenC
    Tuesday, February 22, 2011 9:51 PM
  • Thanks for the suggestion!

    I ended up uninstalling SP1 and will probably leave off our development machines until Microsoft issues a real fix.

    Tuesday, February 22, 2011 10:09 PM
  • I'm having the same problem, installed sp1 on windows 7 and people with no sp1 or people on xp cannot run our software.

    Hope that the fix comes quickly, cause I cannot know if all my clients installed sp1 so I cannot install sp1 myself :-(

     

    Wednesday, February 23, 2011 2:00 PM
  • I just checked the type libs again and it seems that the typedef for ADO_LONG is the problem, which differs on x64 and x86 which makes them incompatible,

    So the deprecated interfaces are identical to the non deprecated interfaces for x86. Plus the deprecated interfaces of x86 are identical to the new x64 interfaces as both use long and not the typedef'd int64.

    Maybe a better solution would be to only change the x64 type lib and leave the x86 one alone.

    I assume the audience using ADODB on x64 code is by far smaller than those using ADODB on x86.
    So changing just the x64 typelib would only break the compilation of existing code compiled for x64 when int64 types or ADO_LONG are used where the new interfaces require long.

    Did you discuss this solution as well?

    I can understand that keeping a symmetric typelib with all the same interfaces looks cleaner, but is it really necessary?


    -- SvenC
    Wednesday, February 23, 2011 5:44 PM
  • The interfaces with new GUIDs (in Windows 7 SP1) don't have such issue.

    This change causes a break that if your application is re-compiled on Windows 7 SP1 and it uses early binding to ADO, it probably doesn't work on down-level OSes, such as Windows 7 RTM, Vista, etc. Please note that this break only happens when the application is re-compiled. Existing applications should run on Windows 7 SP1 without any problems.

    If you have to re-compile your application on SP1, there are several workarounds:

     


    Workarounds?

    'Probably doesn't work?' Doesn't MS test these things? Change probably to 'definitely doesn't work'.

    You talk about the issue of having to recompile an application as if it was something we don't do very often. I have Windows 7 on my main developer machine. But now - since upgrading to SP1 - I can no longer compile my app because of this change.

    Where is the sense in this? I don't see what the problem was before but now I have to install an KB package on every client machine? Sorry for appearing to rant a bit - but do you think you could have let us know in advance that such a major breaking change was going to happen instead of us finding it by accident and spending hours trying to work out what it was?

    I am using Access 2010 so I cannot re-write my application to use late binding as you suggest. This leaves me with installing the KB package on all machines or copying over an old ADO typelib file which would have been easier if MS had let us know that we should have backed it up from the pre SP1 Windows which now has been lost.

    What on earth happened to backward compatibility?

    Seriously though - what is the point of the change? I have read your post above but I can only see that issue occurring in a minimum of situations whereas the problem created by this change is far greater. Also can you let MS know that if they are going to do something with as big an impact as this - you know like affecting the WHOLE of ADO - could they at least let some news sites know first. Seriously - wasted hours on this already and no doubt will waste lots more. Not happy.

    Thanks for the KB by the way - sorry to appear ratty - but I just feel this could have been handled a lot better.

    Wednesday, February 23, 2011 10:55 PM
  • This is absolutely ABSURD and RIDICULOUS, MICROSOFT! A total failure!!!!!!
    Thursday, February 24, 2011 9:09 PM
  • Never tried and just an idea...I am still stuck on XP for development due to the need to support old machines.

    What happens when you #import the ado dll, and #define all the new ado interfaces to their _deprecated counterpart?



    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
    Thursday, February 24, 2011 9:49 PM
  • How can we use the ADO 2.8 typelib from the RTM of Windows 7 in VB6 on a Win7SP1x64 workstation? When we copy the tlb file and attempt to use it within Project->References it cannot be selected (the tlb file info never appears in the references list).

    Do we need to roll a custom typelib to wrap ADO so we're not competing with the new typelibs on the box? I can't figure out how to use the old typelib since the UUID info matches the new typelib and VB says nuh-uh...I already have this typelib installed.

    PLEASE ADVISE IMMEDIATELY.

     

    Thursday, February 24, 2011 11:31 PM
  • run tlbimp to create the interop assembly. The reference wizard does this in the back end.

    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
    Thursday, February 24, 2011 11:59 PM
  • How can we use the ADO 2.8 typelib from the RTM of Windows 7 in VB6 on a Win7SP1x64 workstation? When we copy the tlb file and attempt to use it within Project->References it cannot be selected (the tlb file info never appears in the references list).

    Try first unregistering the one in %CommonProgramFiles(x86)%\system\ado (perhaps by doing C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 -u "%CommonProgramFiles(x86)%\system\ado\msado28.tlb"). If you get a permissions error, you may have to give Administrators Full Control of HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C}. At least on my machine, TrustedInstaller owned that key and had Full Control; Administrators only had Read.
    Friday, February 25, 2011 12:13 AM
  • exactly the same issue here today. Installed service pk 1 on w7 and I have the same problem. No fix other than to remove the service pack.

     

    This can affect literally hundreds of thousands of applications running on W7 and it should be escalated immediately.


    Jamie
    Friday, February 25, 2011 1:25 AM
  • Remove the service pack. That corrected the problem here.
    Jamie
    Friday, February 25, 2011 1:26 AM
  • DAHAN THAT WORKED! THANK YOU!

    Here are the steps I followed with success:

    1. Open Regedit and locate the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C}

    2. Right click, Permissions, Advanced, Owner, Change owner to Administrators, Click OK, OK

    3. Run C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 -u "%CommonProgramFiles(x86)%\system\ado\msado28.tlb"

    4. Copy msado28.tlb from Win7 RTM/Win2008R2 RTM to your local machine, note the folder for the next step.

    5. Run C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 "{path}\msado28.tlb"

     

    Friday, February 25, 2011 4:49 AM
  • Never tried and just an idea...I am still stuck on XP for development due to the need to support old machines.

    What happens when you #import the ado dll, and #define all the new ado interfaces to their _deprecated counterpart?



    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

    Then you cannot build your code on pre SP1 machines as they would not know of the _deprecated interfaces.
    -- SvenC
    Friday, February 25, 2011 7:58 AM
  • We have exactly the same problem with Windows 7 SP1. 

    It is only fixable by installing the KB983246 on every client computer that you put a compiled EXE on with SP1.

    I can't believe Microsoft have done this.

    One more thing, if you have any customers on Windows 2000 (we do, and I know, nothing we can do about it) they are stuffed.  There is no hotfix package for it and even trying to "force" the new dll's on from a Windows XP build with hotfix doesn't work. (msado15.dll etc)

    Looks like we have to tell ALL of our clients to patch their machines.  Great....

    We can't tell all our clients to patch their machines:

    Hotfix information

    A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described in this article. Apply this hotfix only to systems that are experiencing the problem described in this article. This hotfix might receive additional testing. Therefore, if you are not severely affected by this problem, we recommend that you wait for the next software update that contains this hotfix.

    Seeing the amount of thinking that went in to this issue, i would not trust the hotfix at this point.

    Question: if you would install this hotfix, do other applications that are compiled on Windows 7 RTM still run?

    Friday, February 25, 2011 8:08 AM
  • DAHAN THAT WORKED! THANK YOU!

    Here are the steps I followed with success:

    1. Open Regedit and locate the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C}

    2. Right click, Permissions, Advanced, Owner, Change owner to Administrators, Click OK, OK

    3. Run C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 -u "%CommonProgramFiles(x86)%\system\ado\msado28.tlb"

    4. Copy msado28.tlb from Win7 RTM/Win2008R2 RTM to your local machine, note the folder for the next step.

    5. Run C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 "{path}\msado28.tlb"

     


    @Craig: Would this solution also work with VB6 projects?
    Friday, February 25, 2011 8:16 AM
  • An alternative is to copy the pre-sp1 msado28.tlb and/or msado27.tlb (date 16-10-2010) to
    C:\Program Files (x86)\Common Files\System\ado

    To do this, you first need to make yourself owner of the folder, see http://helpdeskgeek.com/windows-7/windows-7-how-to-delete-files-protected-by-trustedinstaller/

     

    The question with both approaches (Dahan/Craig's) and this one, is does a next patch from Microsoft overwrite these?

     

    Friday, February 25, 2011 8:20 AM
  • @p_sie Yes this did work for our VB6 projects.
    Friday, February 25, 2011 4:59 PM
  • If you compile the project on Win 7 RTM, it will run on Win7 SP1 RTM

    If you ty to compile on Win7 SP1 RTM (Upgraded or Fresh install) it won't compile.  End of story.

    How do I send you a sample project to see the problem, if I am able to make a simple one with the problem?

     

    Hi Neil,

    Could you please share the project by SkyDrive or other file sharing service?

    Thanks,

    Shuhai


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net

     

    To recreate the Win7 SP1 bug with a VB6 project is easy.  Do this...

    On Win 7 RTM PC, create a New Project with one form

    Press CTRL-T to add the Component

    Choose " Microsoft ADO Data Control 6.0 (SP6)(OLEDB)"   < make sure you are using the SP6 OLEDB control.

    With the control on the form, double click the data control and scroll down to the MoveComplete event, and put a comment in it. e.g. 'Do Nothing

    Save the project, and run it to prove it runs.  Of course it will do nothing, but it will compile.

     

    Move the project to the Win 7 SP1 PC and try to run it.

    It will immediately fail with the error "Compile error - Procedure declaration does not match description of event of procedure having the same name"

    This will show the bug in Win 7 SP1 as the only difference is the SP1 upgrade.  The problem occurs on a PC that has been upgraded to Win7 SP1 or a fresh Win 7 SP1 PC.

    I hope this will help you find the problem and it's solution.

     

    Tuesday, March 01, 2011 9:22 AM
  • Same problem here !

    It's incredible... Are you trying to find a solution ?

    Wednesday, March 02, 2011 8:49 AM
  • I had this problem in VB6 on a 32-Bit machine, but can confirm it's solved by using a pre-Win7Sp1 msado28.tlb file.  Here's what I did;

     

    1. Run REGEDIT and go to HKLM\Software\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C}

       Set the permissions so that "Administrators" is the Owner and they have Full Control

    2. Open a Command Window and type;

       CD\Program Files\Common Files\System\Ado

       MD MSADO28

       C:\Windows\Microsoft.Net\Framework\v4.0.30319\regtlibv12 -u MSADO28.tlb

       CD MSADO28

       Copy \\oldfiles\msado*.tlb

       C:\Windows\Microsoft.Net\Framework\v4.0.30319\regtlibv12 MSADO28.tlb

       EXIT

     

    You need to replace "oldfiles" above with the path of where the "old" tlb file(s) are.  All you need is a Windows 7 machine that hasn't had Service Pack 1 installed to get these files from the Program Files\Common Files\System\Ado folder.

    Everything should now be ok!

    To convert our app to use late binding would involve several man weeks of effort so the above fix, which took 2 hours to find, apply and test, was incredibly useful. Thanks to Craig Johnson for providing the basis of the code though.

    I do just want to say that I would shoot (not literally) the people at Microsoft who are responsible for this!

    Wednesday, March 02, 2011 10:13 AM
  • The service Pack 1 also broke my .net 4 .....had to re install that too....
    Jamie
    Wednesday, March 02, 2011 1:41 PM
  •  

     

    that funcion :

     

    Function ConectaBaseDatos2(Base As String, ByRef pcn As ADODB.Connection, _
    Optional EscribeCommitsInmediatos As Boolean = False) As Boolean
       
    Dim Mensaje As String
    Dim attr As Long
    Dim BaseNombre As String
    Dim Intento As Long
    Dim txtTítuloMsg As String
    Dim temp As String
    Dim lCursorSave As Long
    Dim lPaso As Integer


    lPaso = 1
    txtTítuloMsg = "Error al conectar con la base de datos"
    lCursorSave = Screen.MousePointer
    Screen.MousePointer = vbHourglass
    ConectaBaseDatos2 = False
    On Error GoTo BaseMala

    If Base = "" Then
        GoTo Salir
    End If
    BaseNombre = FSO.GetBaseName(Base)


    lPaso = 2
    On Error Resume Next
    If pcn.State = adStateOpen Then
        pcn.Close
        Set pcn = Nothing
    End If
    Err.Clear

    On Error GoTo BaseMala
    lPaso = 3
    Set pcn = New ADODB.Connection
    lPaso = 4
    pcn.Provider = "Microsoft.Jet.OLEDB.4.0"
    lPaso = 5
    pcn.CursorLocation = adUseClient
    lPaso = 6
          
    For Intento = 0 To 1
        lPaso = 7
        Select Case AbrirConexionGenerico(Base, Intento, adModeShareDenyNone, True, pcn)
        Case 0 'conexión realizada
            If Intento = 1 Then
                ConectaBaseDatos2 = True
            Else
                lPaso = 8
                If ProtegerBaseGenerico(Base, True, pcn) Then ConectaBaseDatos2 = True
            End If
            Exit For
        'Case 1 ' contraseña no válida
        Case 2, 3 'base está abierta en modo exclusivo u otros errores
            Exit For
        End Select
    Next Intento
    lPaso = 9
    If Not ConectaBaseDatos2 Then
        If pcn.State = adStateOpen Then
            lPaso = 10
            pcn.Close
        Else
            MsgBox "No se pudo abrir la base de datos " & Base & vbCrLf & _
                   "Compruebe su protección.", vbExclamation + vbOKOnly, txtTítuloMsg
        End If
    End If


    If Not ConectaBaseDatos2 Then
        lPaso = 11
        If pcn.State = adStateOpen Then
            lPaso = 12
            pcn.Close
            lPaso = 13
        End If
    End If
    Salir:
        Screen.MousePointer = lCursorSave
        Exit Function
       
    BaseMala:
        If Err.Number = -2147217865 Then
            Mensaje = "La estructura de la base de datos no es correcta"
        Else
            Mensaje = "Error " & Err.Number & " : " & Err.Description
        End If
        MsgBox Mensaje + vbCrLf + "En función:ConectaBaseDatos2 , lpaso=" & lPaso, vbExclamation + vbOKOnly, txtTítuloMsg

        ConectaBaseDatos2 = False
        Resume Salir
    End Function

     

     

    Shows : 'error 430 : Esta clase no admite Automatizacion o la interfaz esperada . En función:ConectaBaseDatos2, lpaso=3'

    That error message is in spanish, i don't know what message is in english.

    I've compiled it with Windows 7 SP1 Professional Spanish. Executed in Windows 2K3 R2 SP2 Spanish

     

    Compiling the same program in Windows XP Professional SP3 Spanish works ok in Windows 2K3 R2 SP2 Spanish and all other windows.

    Friday, March 04, 2011 9:06 AM
  • Sorry but in my opinion this needs a GDR (critical Windows update), not even a question about it.
    • Proposed as answer by mindserve Saturday, March 05, 2011 12:25 PM
    Saturday, March 05, 2011 3:43 AM
  • It does need a critical windows update.. I had to rollback the SP1. 
    Jamie
    Saturday, March 05, 2011 12:26 PM
  • It does need a critical windows update.. I had to rollback the SP1. 
    Jamie

    I agree also, or is MS going to leave us hanging? How about a little warning next time MS! 

    Didn't anyone hit this problem when the SP was in beta?


    Gary Bouchard
    Saturday, March 05, 2011 4:01 PM
  • Yes, I saw 2 reports of this problem on MSDN forums during the testing period. 

    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
    Saturday, March 05, 2011 4:06 PM
  • Yes, I saw 2 reports of this problem on MSDN forums during the testing period. 
    Does this imply that Microsoft -- or at least the MS reps in the forum -- were aware of the problem before the service pack was released?
    Saturday, March 05, 2011 10:12 PM
  • There is no MS reps in this forum, those who come here are volunteers just like me. 

    I alerted a Microsoft employee back in November, he said he will try to find the correct people. 



    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
    Sunday, March 06, 2011 1:56 AM
  • Hi,

    Our product team is aware of this issue and working on a solution for this breaking change as a high priority. The official solution will come soon. Sorry for breaking your application and deployment.

    Regards,

    Shuhai


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Monday, March 07, 2011 9:24 AM
  • The following code snippet for VS C++ uses the deprecated interfaces as default for project, so it should be backwards compatible with ADO interfaces on older versions of Windows.

    As far as I am testing my project compiled on Windows7 SP1 x64, it runs and creates ADO interfaces on Windows XP SP3 (x86) and works with the database data, previously it returned hresult E_NOINTERFACE during ADO interface creation (_Connection).

    in your "StdAfx.h"

    #import <msado15.dll> rename("EOF", "ADO_EOF") \
    	exclude("_Connection", "_Command", "_Parameter", "_Recordset") \
    	rename("_Connection_Deprecated", "_Connection") \
    	rename("_Command_Deprecated", "_Command") \
    	rename("_Parameter_Deprecated", "_Parameter") \
    	rename("_Recordset_Deprecated", "_Recordset")
    
    Monday, March 07, 2011 3:54 PM
  • The following code snippet for VS C++ uses the deprecated interfaces as default for project, so it should be backwards compatible with ADO interfaces on older versions of Windows.

    As far as I am testing my project compiled on Windows7 SP1 x64, it runs and creates ADO interfaces on Windows XP SP3 (x86) and works with the database data, previously it returned hresult E_NOINTERFACE during ADO interface creation (_Connection).

    in your "StdAfx.h"

    #import <msado15.dll> rename("EOF", "ADO_EOF") \
    
    	exclude("_Connection", "_Command", "_Parameter", "_Recordset") \
    
    	rename("_Connection_Deprecated", "_Connection") \
    
    	rename("_Command_Deprecated", "_Command") \
    
    	rename("_Parameter_Deprecated", "_Parameter") \
    
    	rename("_Recordset_Deprecated", "_Recordset")
    
    

     

    The problem is that you cannot compile that code on pre Win 7 SP1 machines. At least not, if older systems do not get an updated msado15.dll with those deprecated interfaces.


    -- SvenC
    Monday, March 07, 2011 4:01 PM
  • There is a by design change in ADO in Windows 7 SP1 that interfaces have new GUIDs as mentioned above. The pattern is that most of all ADO interfaces (say Connection) have new GUIDs while the old GUIDs are assigned to interfaces named xxx_deprecated (say Connection_Deprecated). The reason of this change is mentioned in KB983246:

    This article (KB983246) was last reviewed in September 2010. How can it explain what's broken by an update published in February 2011??

    V.

    Wednesday, March 09, 2011 8:56 PM
  • I am waiting with baited breath.   I lost the whole day with this problem.   I uninstalled SP1, but my development desktop still has this MDAC change.   I know VB6 is ancient, but it there is so much out there.
    Friday, March 11, 2011 8:56 PM
  • For C++, the following seems to be working for me, to preserve both binary and source/compilation compatibility (replace the path as appropriate for your environment):

    1.  Get a copy of msado15.dll from a down-level system into \Common\3rdParty\ADO_old\ (do not register it)

    2.  in .h/.cpp files replace:

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

    with:

    #import "\Common\3rdParty\ADO_old\msado15.dll" rename("EOF", "adoEOF")

    3.  in IDL files replace:

    importlib("msado15.dll")

    with:

    importlib("\Common\3rdParty\ADO_old\msado15.dll")

    4. if you #import a typelibrary that exposes a recordset/connection/etc. as a parameter replace:

    #import "MyStuff.tlb"

    with:

    #import "MyStuff.tlb" \
        inject_statement("#define _Recordset_DeprecatedPtr _RecordsetPtr")\
        inject_statement("#define _Recordset_Deprecated _Recordset")

     

    This seems to work for C++ code.  I'm still trying to get the right combination of tlbimp parameters/command lines to work for c# (I'm doing a tlbimp on "MyStuff.tlb", but it's generating types named 'ADODB._Recordset_Deprecated' if anyone has some suggestions on how to work around the PIA)

     

    Friday, March 11, 2011 10:38 PM
  • I deinstalled SP1. With the work around described here I could get it to work with ADO, but I also use the VB6 dataenvironment designer (msderun), and this internally also got a Type Mismatch. The msderun.dll itself is from 2000, so I can't replace it with a pre-SP1 version (it already is).

     

     

    Saturday, March 12, 2011 6:43 PM
  • Great job, congrats MS!

    I just spent 10 hours in hunting down this problem ...

    Is there a solution yet?

    Monday, March 14, 2011 8:14 AM
  • FYI there's also a massive ADO handle leak introduced in Windows 7 SP1 (affects existing apps running on SP1, not just rebuilt ones)

    Monday, March 14, 2011 3:48 PM
  • Neither workaround works for me. I am using late binding and the patch that is suggested for downlevel os is 64bit. I can no longer run my compiled programs on 32bit XP like I used to. I have two 64bit windows 7 the one without SP1 compiles for any platform without problem, none of the workaraound suggested so far work for my 64bit Win7 SP1.

    Tuesday, March 15, 2011 8:32 PM
  • Re: KB983246 - Won't install on my Win7 SP1 64bit. Don't expect it to install on my WinXP 32bit clients.

    Re: Re-write your application to use later binding to ADO, or use interfaces with name xxx_deprecated. I am using later binding.

    Re: Keep an old version of ADO typelib (i.e., msado28.tlb) (copy from Windows 7 RTM), then compile your application with the old typelib, instead of the one in your system. Tried it, doesn't work.

    So far no help on this problem from anyone.

     

    Tuesday, March 15, 2011 8:40 PM
  • This is impossible anyway. KB983246 won't install on most systems. I haven't seen it install yet.
    Tuesday, March 15, 2011 8:43 PM
  • Welcome to our world!
    Tuesday, March 15, 2011 8:44 PM
  • yeah,,,, I spent a day on this issue and then uninstalled the service pk 1. 

    Can't believe it hasn't affected any installed programs or Access users.


    Jamie
    Tuesday, March 15, 2011 8:46 PM
  • Genious!
    Tuesday, March 15, 2011 9:09 PM
  • Re: KB983246 - Won't install on my Win7 SP1 64bit. Don't expect it to install on my WinXP 32bit clients.

    Re: Re-write your application to use later binding to ADO, or use interfaces with name xxx_deprecated. I am using later binding.

    Re: Keep an old version of ADO typelib (i.e., msado28.tlb) (copy from Windows 7 RTM), then compile your application with the old typelib, instead of the one in your system. Tried it, doesn't work.

    So far no help on this problem from anyone.


    Strange. What kind of error do you get with late binding?

    That should really work in all situations as no IIDs except that from IDispatch are involved and method and property names did not change.


    -- SvenC
    Tuesday, March 15, 2011 9:13 PM
  • I have an Access 2010 project implemented in our department with about 40 users.  I use ADODB all the way through it and did find this problem last week.  After spending several days trying to find out what happened I realized I just installed Win 7 SP1 on my machine.  I had a very angry Manager when it was all done and had to uninstall SP1 to get it to work again.  We have client machines running everything from XP to Win 7.  After finding this forum I was able to late bind and verify it does work but like was said it is slower.  This is not the first problem I ran into with ADO and Access and early binding.  After the first problem I did find that version 2.8 worked with all OS until now. 

    Thanks again MS.

    Tuesday, March 15, 2011 9:20 PM
  • We are running Windows 7 (with or without SP1 at this time) on our development machines. 

    I'm using the following in my C++ header stdafx.h in some of our Win32 projects specifically using the _Stream Interface :

    #import "C:\Program Files (x86)\Common Files\System\ado\msado15.dll"

    Installing the Hotfix in KB983246 solved the problem for me on target machines running the binaries. The code could now be compiled on all developer machines and runs fine on target systems (in our case, mostly Windows 2003 ENU).

     

     

    Wednesday, March 16, 2011 8:34 AM
  • KB983246 was "not applicable" apparently...

    Rebuilding things is not an option for us.
    Installing a rebuilt application is not straightforward for some applications and some customers.

    People could get the impression that it's only native and not managed applications.
    We tend to think it's affecting .Net applications also, with the old stuff used at the lower level somewhere?

    Wednesday, March 16, 2011 9:25 AM
  • Bitly link for this forum thread : http://bit.ly/fHupWT

    I hope MS hurry up and give some further information on this problem it has wasted a lot of time at our site.

    Wednesday, March 16, 2011 10:48 AM
  • Neither workaround works for me. I am using late binding and the patch that is suggested for downlevel os is 64bit. I can no longer run my compiled programs on 32bit XP like I used to. I have two 64bit windows 7 the one without SP1 compiles for any platform without problem, none of the workaraound suggested so far work for my 64bit Win7 SP1.

    Hi oral-b,

    What error message did u see when u ran the compiled problem on 32 bit XP?

    Shuhai


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Wednesday, March 16, 2011 4:53 PM
  • This is impossible anyway. KB983246 won't install on most systems. I haven't seen it install yet.

    Could u provide the error message (or Windows update log) for the installation failure?

    Thanks


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Wednesday, March 16, 2011 4:54 PM
  • Hi, a KB article has just been release to summary this issue:

    KB2517589: An ADO application that is re-compiled on a Windows 7 Service Pack 1-based computer does not run on down-level operating system

    In the mean time, Microsoft is trying to figure out an easy way to work around this issue.


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Thursday, March 17, 2011 3:39 AM
  • Hi, a KB article has just been release to summary this issue:

    KB2517589: An ADO application that is re-compiled on a Windows 7 Service Pack 1-based computer does not run on down-level operating system

    In the mean time, Microsoft is trying to figure out an easy way to work around this issue.


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Shuhai, do you know what the reasons were for adding the new IID's in SP1?
    Thursday, March 17, 2011 10:47 AM
  • Hi, a KB article has just been release to summary this issue:

    KB2517589: An ADO application that is re-compiled on a Windows 7 Service Pack 1-based computer does not run on down-level operating system

    In the mean time, Microsoft is trying to figure out an easy way to work around this issue.


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net
    Shuhai, do you know what the reasons were for adding the new IID's in SP1?

    The typelibs where incomaptible between x86 and x64 because they used a typedef ADO_LONG which is a long in x86 and long long in x64. With VBA in Office 2010 x64 you could not use Long variables where ADO_LONG was used. So people started to see type mismatch errors when they ran their VBA code on x64 Office.

    They could not change ADO_LONG to long in x64 as that would break compiled apps. So they left the old interfaces which used ADO_LONG, renamed them (compiled early binding code will only use IIDs not caring about interface names) and introduced new interfaces with the old names which only use long and not ADO_LONG.

    Would have been a great relieve for us devs if only the x64 typelib would have been modified in this way. In x86 the xxx_deprecated interfaces are binary compatible with the new ones as AD_LONG == long for x86.


    -- SvenC
    Thursday, March 17, 2011 11:17 AM
  • I think if only the x64 type libs are modified you still cannot automate the new 64bit Office from a 32bit program that references the old type library. 

    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
    Thursday, March 17, 2011 4:41 PM
  • Hi, a KB article has just been release to summary this issue:

    KB2517589: An ADO application that is re-compiled on a Windows 7 Service Pack 1-based computer does not run on down-level operating system

    In the mean time, Microsoft is trying to figure out an easy way to work around this issue.


    Shuhai Shen - I love programming, travel and photographing. Welcome to my blog: http://leonax.net

    Mythical method #5: Microsoft fixes the actual problem so as to not place the onus on developers to change their perfectly working code.  SP1 will have to be blocked in our organization, simple as that.
    Thursday, March 17, 2011 5:08 PM
  • Sheng,

    This still begs the question of how MS came up with the most brain-dead approach possible to fixing the issues they were trying to fix by breaking backward compatibility with past interface versions in probably the MOST eggregious way they possibly could.

    They should never have touched the existing CLSIDs but instead introduced a NEW set of MDAC 3.0 components with new ADO interfaces and migrated everyone forward in the same way they have done for decades. So the old interfaces had problems with some 64-bit situaitons - upgrade (and accept the "no way back" limitaiton of the new version), but to do it THIS way!?? To sneak this majorly-breaking not-backwards-compatible-anymore change into a service pack "in the dark of night" like this??! no way!!!


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    • Proposed as answer by mindserve Wednesday, March 23, 2011 10:58 AM
    Friday, March 18, 2011 2:05 PM
  • This was a big problem for us.  We have many compiled classes and controls that pass around connections and recordsets.  It would have been way too much work to recompile all of those, not to mention breaking compatibility.  We use a dedicated Windows 2003 box for compiling, but since running a project in the IDE was affected as well, this was a big issue.

    Just wanted to thank everyone who suggested/posted the TLB fix.  I changed the permissions and owner in the registry for the 2.7 and 2.8 TypeLib as well as on the Common Files\System\ADO folder.  I then backed up my Windows 7 32-bit SP1 TLBs, unregistered them, and then copied the Windows 7 32-bit RTM TLBs and re-registered them.

    I'm not sure if the 2.7 TLB was necessary, but we still have some older components that use ADO 2.7, so I did that one too.

    In case anyone needs it, the 2.7 and 2.8 registry keys are:

    2.8 - HKLM\Software\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C}
    2.7 - HKLM\Software\Classes\TypeLib\{EF53050B-882E-4776-B643-EDA472E8E3F2}

     

    Friday, March 18, 2011 4:44 PM
  • OK- I think I've got the managed code working now.  After using the steps I described above for unmanaged code, in order to create the RCW, use the following command:

     

    tlbimp /tlbreference:"\Common\3rdParty\ADO_old\msado15.dll" MyStuff.tlb

     

    I was sure I had tried the tlbreference parameter before, but I must have messed something up the first time around.

    Friday, March 18, 2011 7:54 PM
  • DAHAN THAT WORKED! THANK YOU!

    Here are the steps I followed with success:

    1. Open Regedit and locate the key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\TypeLib\{2A75196C-D9EB-4129-B803-931327F72D5C}

    2. Right click, Permissions, Advanced, Owner, Change owner to Administrators, Click OK, OK

    3. Run C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 -u "%CommonProgramFiles(x86)%\system\ado\msado28.tlb"

    4. Copy msado28.tlb from Win7 RTM/Win2008R2 RTM to your local machine, note the folder for the next step.

    5. Run C:\Windows\Microsoft.NET\Framework\v4.0.30319\regtlibv12 "{path}\msado28.tlb"

     

    This also worked for myself/my fellow company developers! I'm on a 64-bit system and developing VB6. However I would like to note the permissions on my machine were not cooperating so in step 2 I gave full control permissions to everyone (added group). Then in step 4 I created a new folder in my ado folder and put the new/correct TLB file in there, and registered to the new one in step 5.

    I attempted this fix a few days ago when I had this problem on my own, but did not think to change the registry permissions. Thank you for figuring this out!


    Monday, March 21, 2011 4:56 PM
  • What a complete waste of time for me -- spent at least a day trying to figure out what SP1 did to my 64Bit C++ Code.   I had to modify code --> where I used to be able to use a LONG_PTR, had to switch over to a LONG.   Also, now that I've compiled against the new SP1 ADO code, I have to ensure that our customers have the right update.   What a royal PITA!

    Microsoft - you really hosed us on this one!    You know better than to break an Interface like this --- how many articles have your own folks written about an interface definition being 'sacred'.

     

    Fix this and release something that actually works!

     

    DH

    Tuesday, March 22, 2011 6:28 PM
  • Shuhai,

    We are encountering the same problems with our ERP-apps (VB6 with ADO). When do you think MSFT will have the "official solution" as a hotfix?
    Do you have some news?

    Tx,

    Patrick


    Wednesday, March 23, 2011 7:53 AM
  • Of source, it has affected my Access 2007 application. Worst of all is that I can't run it even when I uninstalled Windows 7 SP1 (Ultimate CZ; CZ=Czech; I also have Office 2007 CZ.)

    I'm completely stuck!

    Wednesday, March 23, 2011 10:28 AM
  • Absolutely agree with you. I'm having problems with Access 2007 as well.


    Wednesday, March 23, 2011 10:51 AM
  • They have this little disclaimer on this hotfix...says "VB6 is no longer supported" perhaps this should have been addressed before allowing developers to install the service pack 1 for Windows. The service pack certainly could have searched for the vb 6 application on machines and had a warning that it is not compatible...stop! will robinson stop ,do not proceed!

     

    Thought that "it just works" meant that it would work through Windows 7 as promised. 

     

    No one breaks backward compatibility ...if developers did that with their own programs we would be out of business.

     


    Jamie
    Wednesday, March 23, 2011 11:01 AM
  • They have this little disclaimer on this hotfix...says "VB6 is no longer supported" perhaps this should have been addressed before allowing developers to install the service pack 1 for Windows. The service pack certainly could have searched for the vb 6 application on machines and had a warning that it is not compatible...stop! will robinson stop ,do not proceed!

     

    Thought that "it just works" meant that it would work through Windows 7 as promised. 

     

    No one breaks backward compatibility ...if developers did that with their own programs we would be out of business.

     


    Jamie


    I totally agree, I have developed VB6 programs for large companies, that I cannot force to install the hotfix. So what will happen when I need to make
    a new compiled version? Like when I need to remove a bug or add new functionality?

    Do I need to use a pre Win 7 SP1 pc for as long as the companies are using my programs???

     

    How about just reversing this update???? That would be the most simple procedure, no developer has allready programmed with the new libraries, cause they
    cannot update their developing machines!!!

    Wednesday, March 23, 2011 11:13 AM
  • They have this little disclaimer on this hotfix...says "VB6 is no longer supported" perhaps this should have been addressed before allowing developers to install the service pack 1 for Windows. The service pack certainly could have searched for the vb 6 application on machines and had a warning that it is not compatible...stop! will robinson stop ,do not proceed!

     

    Thought that "it just works" meant that it would work through Windows 7 as promised. 

     

    No one breaks backward compatibility ...if developers did that with their own programs we would be out of business.

     


    Jamie

    This is not just a VB6 issue. It applies for MS Access as well... and other applications that use ADO.
    Wednesday, March 23, 2011 11:57 AM
  • How about just reversing this update???? That would be the most simple procedure, ...
    I second that!
    Thursday, March 24, 2011 8:51 AM
  • Here is the kb for the QFE: http://support.microsoft.com/kb/983246 

    There is one section in the kb talk about this issue:

    Important After you install this hotfix on a computer, some applications that run correctly on the computer may not run correctly on other computers.
    there are 2 workaround

    1.   Install the Typelib QFE package on down level OSes in the above KB.

    2. always using late binding:Dim o As Object.

     

     

     

     


    1. Should we ask thousands of our users on down level OSes to ask Microsoft for a hotfix? I simply can't imagine that.
    Thursday, March 24, 2011 10:50 AM
  • That KB states this:  The fix is included in Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1.

     

    SP1 is what broke it, how can that be the fix?

     

    Add me to the list of frustrated developers whose programs were broke. I spent a week so far trying to rewrite one of my programs. Glad I finally found this thread.

    Friday, March 25, 2011 10:38 AM
  • New from microsoft!!!

    Office 2010 instalation on win XP or win 7 (32Bit) computers. Creates the same bug reported here.

    This topic is 35 day's old and there's no real solution to the problem :-( .

     

    Sunday, March 27, 2011 2:25 PM
  • I reversed the update but then had to re install the operating system. I say this is a big problem...
    Jamie
    Sunday, March 27, 2011 2:58 PM
  • PLEASE tell me this is getting fixed. This is NOT acceptable and I cannot rewrite every program I've written in the past 10 years and still do business in the process!
    Monday, March 28, 2011 8:34 PM
  • I don't know if Microsoft realizes how this has affected us all. Thats the ones who found out what the problem is and didn't sit around for a week trying to find out why they can't compile an executable in vb 6. 

    I can't rewrite everything either and most people can't. 


    Jamie
    Monday, March 28, 2011 8:38 PM
  • I had a suite of VB6 SP6 applications developed on a Windows 7 machine that were targeted for 64-bit Windows Server 2003 R2 SP2.  They worked fine 16 days ago.  Now they are broken in exactly the manner describer here!  I had to revert to Late Binding of ALL ADO Objects to regain funcitonality.  Totally undesireable since now I have lost all Intellisence 'helpers' within the VB  IDE for ADO objects (since they are now declared as generic Objects).  YUCK  Can't believe how log it took to find this thread in the forums for this issue.  Lost DAYS and big loss of face with a fairly new client.  Thanks MSFT
    Tuesday, March 29, 2011 12:09 AM
  • > lost all Intellisence 'helpers' within the VB  IDE for ADO objects

    Use a #IF/#Else/#EndIf construct to wrap the definitions:
    #IF <control variable>
        dim as ado objects
    #Else
        dim as generic objects
        dim all constants
    #EndIf

    Define the control variable when developing and testing.  Undefine it when building for QA and release.

    Get the benefit of intellisence during development and the safety of late building for release.

    Tuesday, March 29, 2011 1:51 AM
  • Thanks for the suggestion!

    Don't quite understand the 'safety of late binding for release' comment though.

    I have never had to late bind to make things work in over 15 years of development with Visual Studio tools.

    Always thought that for Windows apps, Early Binding was preferred, and in fact, recommended by Microsoft.  I know that execution timing is better.  Pursued this path ONLY because I was forced to.

    Still, thanks

    Steve

    Tuesday, March 29, 2011 3:11 AM
  • Don't quite understand the 'safety of late binding for release' comment though.

    What i meant was that by using late binding you would be safe no matter which version of MDAC was on the build machine or the target machine.

     

    Tuesday, March 29, 2011 3:47 AM
  • I have 9 Access front ends (SQL 2005 back end) with tens of thousands of lines of code to support.  Changing every adodb call to late binding will be time consuming and the performance will suffer.  Thanks Microsoft.  If this is not resolved Access is dead as a professional tool.
    Tuesday, March 29, 2011 3:15 PM
  • This is a very bad thing that has happened and IMO you have a right to be upset. Microsoft has been giving us hints that Access ADODB is a thing of the past.  And if they do not provide a fix for this, ADODB may very well be finished.

    But please do not give up all hope on Access as a professional tool.

    We can still use ODBC and Passthrough queries. The latest versions of ODBC are very fast and you can directly query SQL Server or Execute Stored Procedures (my personal favorite).

    Because ODBC is an international standard for many types of databases and applications it has a good chance of being around for a long time. Perhaps the time has come to make the switch to ODBC Passthrough queries instead of ADODB.


    Patrick Wood Gaining Access http://gainingaccess.net
    Tuesday, March 29, 2011 3:59 PM
  • @saberman:

    Thanks for your suggestion regarding the #IF/#Else/#EndIf construct! Will dig inside for sure.

    But how to use late-binding, when I have a VB6 form containing a "MSAdodcLib.Adodc" control and need to subscribe for example its "MoveComplete" event?

    Help very appreciated.

     

    Regards,

    Axel

    Tuesday, March 29, 2011 6:18 PM
  • Sorry! 7/SP1 breaks odbc access too!

    What a mess...

    Revert & LAWSUIT its my suggestion.

    thanks.

    Wednesday, March 30, 2011 12:19 AM
  • Sorry! 7/SP1 breaks odbc access too!
    Are you sure of this?  What dll are affected?
    Wednesday, March 30, 2011 12:38 AM
  • Why doesn't Microsoft fix this the one proper way: back out the hotfix completely that should have never been included in SP1, and do that as a critical mandatory update on Windows Update. 

    It seems that they blindly include every QFE/hotfix in the the next SP without thinking about the possibility of regression.  It wasn't like this in the Windows 2000 days.  Each QFE was carefully considered before rolling it into an SP.

    Wednesday, March 30, 2011 12:44 AM
  • Well, I didn't go deeply. Just create the odbc and put on target machine, change connection sintax, and, here is the error again.

    I guess is because the executable still compiled under 7/sp1.

    In fact, the error I am facing is the "430".

    A good news is, I remove sp1 and everything its ok now. Also, after the removal, I feel the computer becomes better.

    Removal was an easy 15 ~30 minutes, 1 reboot, 136000 files out and, amazing, it is ok.

    thanks for all the help.

    jdn

     

     

    Wednesday, March 30, 2011 1:07 AM
  • Just for additional info.

    Even before with win7 64-bit SP1, Access 2010 64-bit. ADO 2.8 and ADO 6 had bugs already. Just to let you people know that even before SP1. However, in Access 2010 64-bit. Older version of ADO 2.0 to 2.7 works in my Access application.

    Wednesday, March 30, 2011 1:54 AM
  • Why doesn't Microsoft fix this the one proper way: back out the hotfix completely that should have never been included in SP1, and do that as a critical mandatory update on Windows Update. 

    They can't do that at this point.  Consider a large shop that has deployed SP1 across all machines.  Any ADO application that was compiled and released after SP1 was deployed would stop working if the hotfix was backed out. 

    The only way to unwind the problem would be to have a new mandatory update with the _Depreciated removed from the methods in the old interface and _New added to the methods in the new interface.  That way any application compiled and depoyed after SP1 but before the unwind hot fix would continue to run and all newly built applications would work on any machine.

    Applications that, according to Microsoft, really needed the new interface would call the _New methods.

    • Proposed as answer by saberman Saturday, April 23, 2011 3:01 AM
    Wednesday, March 30, 2011 2:00 AM
  • I wonder whether Access 2010 64-bit works in SP1. If not, could you give us the detail about the failure scenario?

    (As mentioned by Shuhai before, we are working on this issue. But this is a difficult technical problem and it does take time to figure out whether there are any better workarounds)

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Wednesday, March 30, 2011 2:21 AM
  • I would like to know how ODBC does not work. Could you give us the detail scenario? For example, could you post some code snipplet so that we can understand the issue better.

    Thanks,
    Ming.
    WDAC Team, Microsoft.


    Pak-Ming Cheung - MSFT
    Wednesday, March 30, 2011 2:24 AM
  • Ming,

     

    Thank You for taking the time to post in this forum.

    I am delighted beyond measure to see that The MS WDAC team is taking this seriously, but seriously, I do have a question only your team can apparently answer:

    How was the decision to BREAK THE COM INTERFACE CONTRACT for ADODB Components made in the first place? This was the fundamental failure here, after all...and since this decision has had serious consequences to a VERY wide audience of developers, I would hope that someone in MS would feel that an explanation is in order. For some developers/consultants, their JOBS and REPUTATIONS are at risk through no fault of their own - for the fault of following existing MS Best Practices and published recommendations, and for them, an official word from MS on this issue would be HIGHLY beneficial.

     


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    Wednesday, March 30, 2011 2:42 AM
  • I wonder whether Access 2010 64-bit works in SP1. If not, could you give us the detail about the failure scenario?

    (As mentioned by Shuhai before, we are working on this issue. But this is a difficult technical problem and it does take time to figure out whether there are any better workarounds)

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT

    I have not tested it with SP1. But here's a simple code. (if you're asking me.)

    Dim rs as ADODB.Recordset
    dim i as long
    set rs = New ADODB.Recordset
    rs.open "Select * From MyTable", currentproject.connection,adOpenkeyset, adlockoptimistic
    For i = 0 to rs.recordcount
    debug.print i
    next i

    The error is not trapable in the code but gave the Access error message.

    "The expression On Click you entered as the event property setting produced the following error: Type mismatch"
    "The expression may not result in the name of a macro, the name of a user-defined function, or [Event Procedure]. There may have been an error evaluating the function, event, or macro."

    The error was found at "rs.RecordCount".

    It was my resolved to use

    rs.RecordCount & ""

    so that my code would work in 64-bit.

    It appears that 2.8 and 6 had problem with "RecordCount". I have yet to encounter further/more errors with Access2010 64-bit. (note the sample code work in 2000 to 2007, WinXP 32-bit).



    Wednesday, March 30, 2011 3:12 AM
  • But how to use late-binding, when I have a VB6 form containing a "MSAdodcLib.Adodc" control and need to subscribe for example its "MoveComplete" event?

    AlexH1,

    In general VB6 does not handle events from late-bound objects, specifically for controls you can use the VBControlExtender to catch the MoveComplete event. To make it late bound you must remove the control from all your forms and then must remove the reference to MSAdoDc.ocx from your project. Next each form where you use the control add code like this:

    Option Explicit
    Private WithEvents oAdodc As VBControlExtender
    
    Private Sub Form_Load()
      Licenses.Add "MSAdodcLib.Adodc"
      Set oAdodc = Controls.Add("MSAdodcLib.Adodc", "myctl", Form1)
      oAdodc.Move 1, 1, 2500, 50
      oAdodc.Visible = True
    End Sub
    
    Private Sub oAdodc_ObjectEvent(Info As EventInfo)
      If Info.Name = "MoveComplete" Then
        ' add your code for the MoveComplete event here
        
      End If
    End Sub
    
    I hope this helps.

    Wednesday, March 30, 2011 4:05 AM
  • Thanks in advance Pawaw!

    Will give it a try.

    Wednesday, March 30, 2011 5:58 AM
  • Problem is when I use Microsoft.Jet.OLEDB.4.0 or SQLOLEDB or another oledb provider for the database connection (ADODB).

    In fact I did not now if using odbc provider like MSDASQL will work.

    Other users on this forum are saying odbc works perfectly under 7/SP1.

    Please let me now if I am talking non sense.

    thanks.

    jdn

     

     

     


    jdn
    Wednesday, March 30, 2011 1:16 PM
  • Problem is when I use Microsoft.Jet.OLEDB.4.0 or SQLOLEDB or another oledb provider for the database connection (ADODB).

    In fact I did not now if using odbc provider like MSDASQL will work.

    Other users on this forum are saying odbc works perfectly under 7/SP1.

    Please let me now if I am talking non sense.


    jdn

    So you just changed the provider you use in your connection string but still use ADODB classes and interfaces, right?
    The change in interface IDs has nothing to do with the provider you use.

    Patrick is talking about switching the API to ODBC, which is a C API. Not sure if any VB wrappers (besides ADODB ;-) ) exist or if you can come along with declare function statements. Nevertheless it would be quite a big rewrite and retest of your app.

    I would recommend that you either uninstall SP1 or replace and reregister the dlls in c:\program files (x86)\common files\system\ado on your dev machine like described earlier. That will build against the old interface IDs and will run on any Windows version with old or new MDACs.


    -- SvenC
    Wednesday, March 30, 2011 1:48 PM
  • Sven, I agree.  What I was talking about was Microsoft Access development and would require rewriting all the code that uses ADODB and changing it to use Passthrough queries recordsets and action queries. I know that this is not an option for a lot of people and they have to use a workaround such as you described or rewrite the code using late binding.

    I was mainly talking about new development from now on.

    If anyone is interested I have some examples of using ODBC Passthrough queries with recordsets here and action queries here.


    Patrick Wood Gaining Access http://gainingaccess.net
    Wednesday, March 30, 2011 2:23 PM
  • Sam,

    I'm in the same mood and for the same reason. Just lost a full day tracking this issue until I found this and a very few other threads. I usually trust Windows updates and like to have my workstation up to date. Wrong!

    I'm aware that VB6 is not supported and that "the VB runtime will be supported throughout Windows 7 life cycle", as stated by Microsoft. That's why we don't promote or do new development in VB6, C++/COM and even .net COM interop if we can (VB6 was the friendlier COM development platform for us anyway). However, a totally different thing is to deliberately break backward compatibility. VB6/ADO binaries that require sporadic maintenance DO EXIST in production environments everywhere. Why would you break deliberately such an important piece of Microsoft's platform, legacy or not? 

    This issue will surely break a lot of code around the world as unaware developers using Win7 SP1 compile and deploy maintenance builds of legacy apps and components, as we did. And that costs red faces and money!

    Silly workarounds are not an option.

    Rants off, the best solution for us was to set up a Virtual WinXP Box and compile there. We also added some logic to detect and report if the "old" ADO IIDs change again due to one of the workarounds proposed by MS, that is, to install the new IIDs in old workstations/servers. Yuck!!!

    Thanks for the info and Regards.









    • Edited by lbrass Wednesday, March 30, 2011 9:28 PM editing typos
    Wednesday, March 30, 2011 8:53 PM
  • I can confirm that Win 7 SP1 breaks Access apps using odbc SQL Server and even its own native tables when ADO Recordset or Connection methods are called.  As far as I can tell, SP1 installs new ADO libraries that overwrite the old ones.  The file names are the same, but the file size and system identity are different (couldn't they have put in a new library as ADO 3.0 and left the old ones alone?).  After compiling under Win 7 SP1 apps start throwing 430 and 91 errors.  I'd like to call Microsoft stupid, but this is actually very clever.  In one clandestine stroke they've made a major structural change that no doubt suits their purposes, but they did it in a way that ensures that developers and sys admins will catch all the flak when the inevitable problems occur.

    Thursday, March 31, 2011 1:02 AM
  • Could you give us detail of the ODBC issue? For example, code snipplet.

    We need all of these data to improve the product.

    Thanks,
    Ming.
    WDAC Team, Microsoft.


    Pak-Ming Cheung - MSFT
    Thursday, March 31, 2011 1:49 AM
  • I'm aware that VB6 is not supported and that "the VB runtime will be supported throughout Windows 7 life cycle"

    It is the VB6 IDE that is not supported.  Office 2007's VBA is VB6.5 which is fully supported.  So if you find an interface problem in VB6 and can reproduce it in any of the Office 2007 products' VBA Microsoft is still supposed to address and fix the problem. 

     

    Thursday, March 31, 2011 2:07 AM
  • It is not an odbc issue; it is an ADO issue that manifests in Access apps that link SQL Server tables using odbc and / or that use native Access tables when the an app is compiled on a system running under Win 7 SP1.  After making code changes to a well established app I compiled under Win 7 SP1 and then immediately got Error 430 when a Recordset object is called as follows:

    Dim RstCalcItems As New ADODB.Recordset

    RstCalcItems.Open "Select ItemQuantity,ItemID,ItemPrice,ItemCouponCode,ItemDiscRate,ItemDiscount,ItemAdjPrice From OrderItems Where OrderID=" & OrderID & ";", CurrentProject.Connection, adOpenDynamic, adLockOptimistic

    I also got Error 91 when a Connection object is called as follows:

    Dim Cn As ADODB.Connection
    Set Cn = CurrentProject.Connection

    The code changes were not related to the lines above, nor to ADO at all.  These problems did not occur with Win 7 before SP1.  The app still references ADO 2.7, but that library is apparently a different animal after SP1.  A VERY bad idea, as this forum makes clear.

     

     

     

    Thursday, March 31, 2011 2:30 AM
  • Can anyone confirm that it's also the same problem the other way around:

    Dev PC: XP VS2008 or VS2010
    Customer PC: Win7 SP1

    not

    Dev PC: Win7 sp1 VS2010
    Customer PC: XP

    Or is this a different problem?

    Thursday, March 31, 2011 8:59 AM
  • No, there should not be the same issue for the configuration:

         Dev PC: XP VS2008 or VS2010
         Customer PC: Win7 SP1

    If you find any issue in the above configuration, please give us detail repro (e.g. code snipplet, symptoms).

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     

     


    Pak-Ming Cheung - MSFT
    Thursday, March 31, 2011 9:46 AM
  • Ming,

     

    Do me a favor, please.

    Develop something semi-formal but quite useful in Access VBA using ADODB components and run it on your non-Win7Sp1 Dev PC.

    Then copy the UNCOMPILED .mdb/.accdb (meaning not a .mde /.accde) from your dev machine to another PC with Win7Sp1, and make some tweaks (as one might do in a quick & dirty dev/test cycle in some environments)...being sure you recompile the VBA code on the win7sp1 machine, and then copy it back to your dev machine and try to run it. Then tell me again how there are no issues with this configuration.

     

    We do this sort of thing ALL THE TIME in the real-world life of Access developers. You just threw a big monkey-wrench into the MS Access world, and if you don't fix it - and soon -  Access will die as a development platform and soon thereafter as a product. NOBODY with half a brain will do anything serious with it ever again, and it would STUN YOU how big an impact that will be.

     


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    Thursday, March 31, 2011 11:13 AM
  • saberman,

    What? You're suggesting that they follow their own rules for COM interfaces again after all these years of being faithful to them previously!?  HERESY!! :-P


    Mark Burns, MCAD, MCP
    Sr. Microsoft Access Analyst/Developer
    Manager LinkedIn.Com community: Professional Microsoft Access Developers Network (PMADN)
    Thursday, March 31, 2011 11:19 AM
  • saberman,   Indeed it would be safer since not using the IIDs to instantiate.  However, it is not practical to modify 100's of applications that are already in production in this manner.  Add to that fact that we have 100's more Active X DLLs, all using AD0 and you have a sizable nightmare scenario. 

    Our solution ... continue modification & testing on our Windows 7 machine (most of which now have SP1 applied ... oh BTW;  The one we tried to remove SP1 from needed to be completely restaged!).  Anyway we have retained an old WinXP SP2 laptop we will be doing final recomile on prior to production rollout!

    MS really screwed up on this one ...

    Thursday, March 31, 2011 1:58 PM
  • Not entirely sure of this posting.  I had Office 2010 on a Windows 7 (32-bit) machine prior to SP1 getting applied and everything was fine.  It was AFTER Windows 7 SP1 getting applied that everything using ADO went to hell.

    As far as the 35 day old bug with no solution ... look at the similar timeline on this thread which took me days to find (thought it was a Windows Server 2003 64-bit issue at first).  For every developer posting here there are probably 100's that gave up looking

     


    Steven Thebo Systems / Software Engineering Consultant
    Thursday, March 31, 2011 2:25 PM
  • Not entirely sure of this posting.  I had Office 2010 on a Windows 7 (32-bit) machine prior to SP1 getting applied and everything was fine.  It was AFTER Windows 7 SP1 getting applied that everything using ADO went to hell.

    As far as the 35 day old bug with no solution ... look at the similar timeline on this thread which took me days to find (thought it was a Windows Server 2003 64-bit issue at first).  For every developer posting here there are probably 100's that gave up looking

     


    Steven Thebo Systems / Software Engineering Consultant


    I'm developing with Delphi and i was only looking this thread since it started.

    In my work, only i'm working with Windows 7 and i had to uninstall SP1 from my machine.

    I'm waiting for a solution with a big number of developers that only look to this thread each day waiting for a solution...

    Thursday, March 31, 2011 2:52 PM
  • Sounds like someone dropped the ball in a very serious fashion somewhere.  To release a patch that already had notifications of problems or this magnitude associated with it is beyond reckless.  Further, I seem to recall something similar happening with XP SP2 and MS should have learned from that past mistake.  Does anyone there care about how much this has cost their (once loyal) developer community?  Does anyone at MS care?
    Steven Thebo - Systems / Software Engineering Consultant
    Thursday, March 31, 2011 5:05 PM
  • Ming,

    You seem to be are the only Microsoft employee following this discussion thread, so I direct this to you as a plea as a Windows developer caring for my (and your) customers.

    Please escalate this issue to upper managment, ideally to any retired COM evangelist still at Microsoft. He will confirm you that this, effectively is heresy from a theoretical (and practical) point of view, as Mark Burns stated earlier. At least, Microsoft should warn developers NOT TO BUILD ADO dependant code on Windows 7 SP1 machines meanwhile you research the problem. Applying the hotfixes posted on MS support might cause far more problems on the long run, as binaries with different binding IIDs get installed in the affected workstations/servers.

    If you need any help, evidence or whatever please feel free to ask.

    Thanks,

    lbrass.




    • Edited by lbrass Thursday, March 31, 2011 8:02 PM
    Thursday, March 31, 2011 7:27 PM
  • Try this with caution.  The one machine my group tried to remove SP1 from required being restaged afterward!  Anyone else have similar problem removing SP1?
    Steven Thebo - Systems / Software Engineering Consultant
    Thursday, March 31, 2011 7:33 PM
  • I don't know the number of ADO clients currently using early binding to the updated type library, but this problem cannot be fixed without causing further incompatibilities based on number of replies from some users that indicate they choose to upgrade the users with the hotfix here. Also the change is by design to accommodate 64bit COM servers (e.g. for 32bit client that automate 64bit Officeout-of-proc), so stick to the old type library isn't a long-term option.

    Microsoft's suggestion on Office automation is to use late binding whenever possible.

    Quote:

    Developers who use early binding should be aware that if they recompile their project in Visual Basic, it is possible that their project will automatically upgrade their reference to a new version of the type library, causing that project to work only with that version of Office and later.

    and 

    Clients who want to use early binding should bind to the oldest version of the Office application to which they want to be compatible.

    I think these suggestions apply to ADO as well.



    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

    Thursday, March 31, 2011 7:53 PM
  • I'm aware that VB6 is not supported and that "the VB runtime will be supported throughout Windows 7 life cycle"

    It is the VB6 IDE that is not supported.  Office 2007's VBA is VB6.5 which is fully supported.  So if you find an interface problem in VB6 and can reproduce it in any of the Office 2007 products' VBA Microsoft is still supposed to address and fix the problem. 

     


    saberman,

    VB6 IDE is what we use to do maintenance builds of legacy COM components and even applications, not VBA.

    VBA might be alive because it is being carried onward by the Office platform. However, issues like this one, clearly show that Microsoft is not paying any attention to VB6-built components and apps out there. ADO is part of the VB6 ecosystem, and if Microsoft state that it (VB6) will be supported at the runtime level during the Windows 7 life cycle, one expects that ADO will we be too.

     





    Thursday, March 31, 2011 7:58 PM
  • Hi people.

    Is there any official response from Microsoft? It is or it is not a definitive change in ADO behavior / breaking compatiblity?

    As a summary, after almost 2 months discussion here, I could figured out that:

    1) The SP1 for Win/7 64 changes msado27 and msado28 libraryes and its type lib files (.tlb). Also its improve a protection on its registry key avoiding any attempt to restore back pré-sp1 versions.

    2) As a consequense, any applications which uses ADODB methods (I mean ANY), compiled under this SP1 version wil fail to run under ANY other OS.

    3) It is fact that, if an appplication using ADODB compiled under other OS non Win7/SP1 runs fine in any other OS including in Win7/SP1.

    4) As the re-write code is not an option for the majority of the earth programmers,  We have two good suggestions to solve the problem:

    a) it is posible to restore those libraries to pré sp1 version using a few procedures (like Dahan / Craig suggested). I try it and works!

    b) Also, is suggested  to remove the SP1. I tried it and wotks. As a colateral of removing SP1 is that my local IIS7 crashes.

    Our platform is VB6, with ADODB, for MSACCESS/SQL/ORACLE, and several users around the world.

    Of course we are pushing our team to the new techs, And, of course, these Microsoft mess is making us revise our budget to invest in other platforms.

    Facing the facts, world is changing. The new huge trend is in the store and its name is iPad / Tablets. 

    Maybe this is the tip we need to let dinossaurs in their fossil museum and put our money in a fresh new way of thinking software.

    Thanks for all your help.

    jdn

     

     


    jdn
    Thursday, March 31, 2011 7:58 PM
  • I just reverted back to pre SP1 and then reinstalled the OS since removing the SP1 was a big problem. it was a mess for me but happily it is working again. The compiled applications worked..I just could not get the VB6 IDE to compile an executable at all. How odd...

    Did anyone have a problem with compiled applications running properly after SP1 was installed?


    Jamie
    Thursday, March 31, 2011 8:03 PM
  • One work Mark ... Amen ...

    Keep preaching at them!

    Seems like you understand this better than the MS repliers anyway ...


    Steven Thebo - Systems / Software Engineering Consultant
    Thursday, March 31, 2011 8:24 PM
  • I don't know the number of ADO clients currently using early binding to the updated type library...


    Sheng,

    Believe me, potentially its HUGE!!!...  and many times hidden everywhere in the form of COM (ActiveX) components, very difficult to track down or debugged once installed. Most important, why would you suspect a faithful component that has worked for years will suddenly fail with no reason? (no changes on the COM host)... Oops, sorry, I recompiled in Win7 SP1.

    The scope of this issue should be broadened past away just Office, its ADO as part of a trusted platform. Conceptually, Office is just a set of applications. Why break the platform to accomodate Office?

    Regards,

    lbrass




    Thursday, March 31, 2011 8:57 PM
  • We definitely understand that this "design change" has already caused a huge customer impact among most 32-bit ADO developers who would like to recompile on Win7 SP1 (for servicing, for new version, etc.) and target for downlevel machines.

    Therefore, we are working hard to find out a good solution. Also, our management is aware of this issue. Yep, one of the temporality solutions might be developing / building ADO on Win7 RTM (pre-SP1) for a moment.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    • Proposed as answer by lbrass Friday, April 01, 2011 7:10 PM
    Friday, April 01, 2011 1:23 AM
  • Cheung,

    Thank you for the feedback.

    I found another possible bug. Without SP1 - Win7 64-bit Access2010 64-bit SQL Server Express 2005.

    Here a simple code for testing.

    Private Sub Command0_Click()
    Dim Con As ADODB.Connection
    Dim strCon as String

    Set Con  = New ADODB.Connection

    strCon = “DRIVER=SQL Native Client;SERVER=MyServer\sqlexpress;Database=MyDB;Trusted Connection=No;UID=xxxx;PWD=xxxx;”

    Con.Open strCon
    Debug.Print Con.ConnectionString
    Set Con = Nothing
    End Sub

    Note of the print out of the connection string in the immediate window. “Provider=MSDASQL.1”.

    The connection to the Server works. However, it's no longer the correct string output. Normally I use a Global connection to a SQL Server Login. This connection method can no longer be use.  This might be the problem arising from multiple complaints of ADO?

    Perhaps, these are the few changes done?

    My current machine setup is only temporary, would not be using Win7 and Access 2010 64-bit for the moment.

     




    Friday, April 01, 2011 2:53 AM
  • VB6 IDE is what we use to do maintenance builds of legacy COM components and even applications, not VBA.

    VBA might be alive because it is being carried onward by the Office platform. However, issues like this one, clearly show that Microsoft is not paying any attention to VB6-built components and apps out there. ADO is part of the VB6 ecosystem, and if Microsoft state that it (VB6) will be supported at the runtime level during the Windows 7 life cycle, one expects that ADO will we be too.

    The point I unsuccesfully tried to make is that problems with the COM interface affect Office 2007 applications just as they do VB6 application.  (It also affects .Net and other platforms as well.)  That is the reason that this has to be seen as a major MS mistake and one that they should rectify as soon as possible to provide support for the products that are not past end of life.
    Friday, April 01, 2011 3:23 AM
  • This is a totally different issue and this is not a regression from Win7 SP1.

    Starting from Vista, ADO will by-default remove the sensitive information such as password and extended properties from the output connection string. Since you are using MSDASQL (OleDB Provider for ODBC driver), most ODBC connection string attributes are grouped into an OleDB property called "Extended Properties".

    To workaround this, please append "Persist Security Info=True" to your connection string. For example,

    “DRIVER=SQL Native Client;SERVER=MyServer\sqlexpress;Database=MyDB;Trusted Connection=No;UID=xxxx;PWD=xxxx;Persist Security Info=True

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Friday, April 01, 2011 4:45 AM
  • Ming,

    Thanks for your reply. I wish you and the WDAC team luck while you solve the issue with a smart solution.

    Legacy software should be left to die in peace, as developers focus their minds and resources on new technologies instead of solving this kind of issues.  

    As you may know, corporate clients don't upgrade the desktop OS at the same speed as developers and home users do. My experience with corporate clients is that they skipped Vista so they are still on Windows XP and just starting to move (slowly) to Windows 7 and Windows Server 2008.

    Friday, April 01, 2011 2:24 PM
  • saberman,

    I get it now, at the time I was focused on my particular problem. Will do some tests right away to check the impact on .net.

    Thanks.

    Friday, April 01, 2011 2:31 PM
  • This is a totally different issue and this is not a regression from Win7 SP1.

    “DRIVER=SQL Native Client;SERVER=MyServer\sqlexpress;Database=MyDB;Trusted Connection=No;UID=xxxx;PWD=xxxx;Persist Security Info=True

    Ming,  Thank you very much for the alternate advice on that. Does MS web site have this information? The reason I'm asking is because there aren't any web site on this. All I have seen is the is "Integrated Security=SSPI", nothing on "Persist Security Info=True".

    I wasn't aware of this changes to Vista and Win7, I think most of us do. Do you have a link to MS site to confirm this?

    If we need that, I think the external web sites on connection-strings have to be updated ASAP.

    We know you're working hard on solving the problem and we appriciate your efforts.

    Saturday, April 02, 2011 10:39 AM
  • Connection strings and the behavior they control are provider-specific so the place you need to look for SQL Native Client is SQL Server Book Online.

    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
    Saturday, April 02, 2011 1:44 PM
  • WOW!!!

    I am an Access Developer and I'm here to add just a few things to this conversation.

    This problem hit me about a week or two ago and I only found this article through Experts Exchange and thank goodness I did, I had no way to fix these problem.  I have an .adp that i recently migrated from XP clients to Win 7 Clients and everytime i use an ado recordset like this i got an error like this:

    Method 'Connection' of object '_CurrentProject' failed

    On Error GoTo ErrorHandler
     Dim rs As ADODB.Recordset
     Set rs = New ADODB.Recordset
     
     Dim strSql As String
     Dim strCurrentProjectPath As String
     
     blnCurrentPathUsed = False 'keep track of wether attempts to use the current path were used and if they failed
     strCurrentProjectPath = CurrentProject.Path & "\"
     
     strSql = "SELECT * FROM tbllkupProgramOptions WHERE MachineName = """ & fOSMachineName & """"
     rs.Open strSql, CurrentProject.Connection, adOpenForwardOnly, adLockPessimistic
     
     If rs.EOF = True Then ' No Options for this computer so Add Defaults
        rs.Close

    ..blah

    Method 'Connection' of object '_CurrentProject' failed

    So I wasted about 48 hours trying to fix/find the cause.  What i found:

    .accde projects compiled on target machines without sp1 work on all target machines.  .accde projects compiled on my Dev machine with win7sp1 fail.  I'm not quite sure why i should have to use late binding for all my ADO code, I've had this project for 10 years now and its always worked fine.  I changed all my dao code to ado back in the day, and thought ado would be fine for the foreseeable future.  So now i have uninstalled service pack 1 from my dev machine and recompiled and deployed the .accde to a xp sp3 machine and i still get the problem on all my currentproject.connection ado code.  I also get this problem on another win7 machine I deployed to without sp1.  So just uninstalling sp1 did not fix my problem with access 2010 (32 bit) and win7 (64 bit)

    To echo what was said above, i have often thought of dropping access as a dev platform especially when one version comes out it breaks something that worked before (package solution 2010 would be a great example) but this latest glitch is a tremendous dissapointment for my access proejcts.  Stating that i should go back and rewrite thousands and thousands of lines of code is just a ridiculous "workaround."  I expect VBA to be supported beyond VB6 and the fact that ado quits working on me out of the blue is very frustrating.  Well i managed to grab an old version of msadox.dll and msado15.dll and that combined with the removal of sp1 from Win7 made it all work.

    UPDATE:

    I should note that as part of my software i have a startup wizard that reregisters all activex and com components that i include with the access package.  i manually reregister those as part of the first run of the software, and now I will stay away from SP1!!  So the access fix to be clear is: Uninstall sp1 from Win7 dev machines

    wusa.exe /uninstall /kb:976932

    Then make sure to package the older version dll of msado15.dll (2.81.1138) and I assume also if you use msadox.dll (2.81.1128) if you use that library.  Recompile your code, compile the .accde and create your package and done.

    David






    Sunday, April 03, 2011 5:05 PM
  • I should note that as part of my software i have a startup wizard that reregisters all activex and com components that i include with the access package.  i manually reregister those as part of the first run of the software, and now I will stay away from SP1!!  So the access fix to be clear is: Uninstall sp1 from Win7 dev machines

    wusa.exe /uninstall /kb:976932

    Then make sure to package the older version dll of msado15.dll (2.81.1138) and I assume also if you use msadox.dll (2.81.1128) if you use that library.  Recompile your code, compile the .accde and create your package and done


    There are two problems with your approach: Technical and Legal

    Technical: If your software is installed on a Windows 7 SP1 machine and you replace the new MDAC dll with the old one you will break any application that was compiled on that machine after SP1 was installed.  So applications developed inhouse and deployed by your clients after SP1 was installed will start failing -- of course your application will still work.

    Legal: I don't believe the MDAC dlls are part of any redistributable package since they are considered part of the OS.  Can someone from Microsoft please comment on whether a special license is needed to redistrute the MDAC package?

    Sunday, April 03, 2011 8:46 PM
  • The mdac's are in executable form and if it needs to be distributed or downloaded I don't think thats a problem as long as it's distributed as the full executable.

    My compiled vb 6 programs and vb net programs had no issues after the sp1 was installed. I just could not get the vb6 IDE to compile an executable. No issue with compilation on the vb net at all.

     

    But I did have to uninstall the SP1 so I could compile and work in the vb 6 IDE.

     

    Access backend databases 2003.

     

    After I uninstalled SP1 I had to reinstall my OS which was not making me a happy camper that day for sure.


    Jamie
    Sunday, April 03, 2011 9:05 PM
  • The mdac's are in executable form and if it needs to be distributed or downloaded I don't think thats a problem as long as it's distributed as the full executable.

    My compiled vb 6 programs and vb net programs had no issues after the sp1 was installed. I just could not get the vb6 IDE to compile an executable. No issue with compilation on the vb net at all.

    Microsoft makes available certiain redistributable packages.  It is my understanding that you can only included in a application distribution package those binaries that Microsoft has designated as redistributable.  But that is a legal question and I am not qualified to provide an answer.

    When you had the problem with compiling using the VB6 IDE was it because the MDAC reference was broken or because the signitures of the mehods changed?

    Sunday, April 03, 2011 9:48 PM
  • I don't think it was the mdac since I tried to reinstall that and nothing happened. If it was broken, then the compiled apps would not have functioned at all I believe. That's happened in the past on XP, the mdac components broke for some odd reason or another and the mdac had to be repaired for the applications to work ( same apps that failed to compile with the SP1)

    So something changed... 


    Jamie
    Sunday, April 03, 2011 10:00 PM
  • So your saying microsoft would sue me for damages because their upgrade broke my software and I reverted to distributing the versions not included with windows 7 sp1? 

    That would be par for the course.  We broke your software because we didn't test this upgrade and by the way you owe us a million dollars because of your workaround..... I couldn't tell you if it was a reference or signature issue but i'd assume both, the reference to the msado.dll was version 6.0.xxxx and it was about 900k the pre sp1 versions were 2.8.xxxx and around 200k.

    Also I am not replacing the dlls on my development machine only the references to what is used.  I make my package reference the 2.8 versions not the 6.0 versions so no harm no foul on software compiled to use the 6.0 versions on other pieces of software, besides until a month ago all backward compatibility worked fine so i can't see how my work around would affect other pieces of software on my dev machine.

    All i know is I gotta make it work and my company and users kicks my butt when my software breaks for no reason and the vice president really doesn't care to hear some sob story about how microsoft messed up and they are working to fix it.  The buck stops with me and i gotta make it work however i can.  This is a known issue 2 months old, when MS releases a proper fix I'll use it until then i gotta make it work end of story.

    David







    Monday, April 04, 2011 4:46 AM
  • So your saying microsoft would sue me for damages because their upgrade broke my software and I reverted to distributing the versions not included with windows 7 sp1? 

    Well David you're not alone in this, they'll have to sue some 1000000 developers just for losing our jobs, and 500000 companies that lost their client's, but they be happy for opening 100000 new development projects for the existing solutions that where broken.

    And as I've mentioned earlier installation of office 2010 creates the same MDAC ADODB COM problem as sp1 even on xp computers.

    http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/2b447a4f-b7d4-473f-ae54-bff789457596

     

    Monday, April 04, 2011 5:47 AM
  • And as I've mentioned earlier installation of office 2010 creates the same MDAC ADODB COM problem as sp1 even on xp computers.

    http://social.technet.microsoft.com/Forums/en-US/officeappcompat/thread/2b447a4f-b7d4-473f-ae54-bff789457596

     

    What error message did you get?

    I have Office 2010 on my dev machine for a long time and did never encounter any ADODB problems in that combination.
    Maybe you are seeing a different problem here?


    -- SvenC
    Monday, April 04, 2011 5:58 AM
  • I hope we could see a change in the new ADODB type library, but I think chances are not too big.

    The problem introduced with the ADO_LONG typedef long time ago is hard to fix pleasantly for all devs and users.

    But if Microsoft thinks that the changes of ADODB as they were introduced in Win7 SP1 are here to stay, then please reconsider your policy of how to get the updated MDAC to any pre Win7 SP1 machine. A hotifx is way too complicated if our customers have to distribute it to lots of machines. Make it at least a recommended Windows Update download so that chances are good that apps compiled on Win7 SP1 will simply run on others Windows versions. *And* even more important, give us an update package (merge module) which we can use for redistribution so that our setups can include this MDAC change to ensure our software works even if customers do not use Windows Update regularily.


    -- SvenC
    Monday, April 04, 2011 6:11 AM
  • The real problem is inconsistent behavior. As we all know there is too many office releases from Microsoft. Some of the installations do create this type of behavior specially the upgrade versions, or the versions downloaded by product key. The full CD version behaves completely fine. Some errors are Method 'Connection' problems, some have to do with compatibility of 64-bit ODBC driver for Microsoft Access. Any-Way I look at IT it's a mess.
    Monday, April 04, 2011 8:29 AM
  • The real problem is inconsistent behavior. As we all know there is too many office releases from Microsoft. Some of the installations do create this type of behavior specially the upgrade versions, or the versions downloaded by product key. The full CD version behaves completely fine. Some errors are Method 'Connection' problems, some have to do with compatibility of 64-bit ODBC driver for Microsoft Access. Any-Way I look at IT it's a mess.


    I will definately agree there, i have developed on every version from 2000 to 2010 and its appalling how one version will introduce new features only to break existing features like the package wizard in 2010 not being able to include directories but 2007 could....  So then i have to write custom code to attatch an archived zip of my files and then unzip them on the first run.  Its just annoying. 

    I've never had an MDAC problems up until this release of office but this is squarely connected to sp1 win7, but then again i usually don't buy upgrades i get full versions because of the same reason i wont upgrade a windows OS, upgrades are pretty much assured never to work right and clean installs are your best bet at a happy life.  I also have learned never to adpot any technology that is introduced into a new office version ever since it will most likely be discontinued in the next version.  (Anyone remember 2000's Data Access Pages?  What a joke...)  I'm wondering if this new 2010 integration with sharepoint will still be around in 2012/2013 office, but i digress into ranting.  This is the same reason i am not installing 64 bit either.  If Microsoft reccommends 32 bit office even though 64 bit is available thats plenty good enough for me to stay on 32 bit even though i can't think of too many people not running 64 bit machines these days if you want more than 3gb of ram, including myself.

    For instance when our corporation upgraded from XP to Win7 for a split second i though wow i could just get one copy of pro plus and just deploy the runtime to everyone and save about 100 bucks per computer on the standard office, then i said to myself yeah are you really sure thats going to work correctly... and so I gave microsoft a boatload more money for the pro plus with access. This way I know if i ever have to use the accdb i can, and wouldn't you know it this ado breakage problem crops up within 2 months of our 50 pc upgrade....

    But thats for our corporate .adp project and i still have projects for other people where I have to have the runtime version deployed...

    David






    Monday, April 04, 2011 2:51 PM
  • This gets even better.  If you compiled on Win7 SP1, down level OS's do not function.

    If like myself you are forced to still use Windows XP as a VB6 development environment, because moderatly sized MS Source safe bound projects crash VB6 with no explination; then you're in for a suprise.

    If you, like me, install the KB hot fix on your XP box, and compile anything.  That application will not function on any Windows 7 machine that does not have SP1.

    So last week I pushed out the patch so my Win7 services could function on two servers.  Then on Friday, 4pm, I released my main buisness app, compiled on XP, and within a few minutes I had 50 non-functional employees.  Fun times.

    We were forced to push out Win7 SP1 over the weekend.  Sadly 2 machines did not survive the upgrade.  That's not typical for SP's, no bashing here, but it did happen.

     

     

     

    Monday, April 04, 2011 5:13 PM
  • Did MS work on it 3 years ago? See http://blogs.office.com/b/microsoft-access/archive/2008/06/19/tech-talk-using-access-with-sql-server-panel-discussion-from-tech-ed-2008.aspx, search for "DAO is your friend".
    Monday, April 04, 2011 9:26 PM
  • We were forced to push out Win7 SP1 over the weekend.  Sadly 2 machines did not survive the upgrade.  That's not typical for SP's, no bashing here, but it did happen.

    Service Packs have to go through the same vetting as a new release of an OS before you deploy them.  There have been some -- not many -- instances of a Service Pack hosing a machine.  If I recall correctly -- and my memory bank is starting to have ECC errors -- one Service Pack killed internet connectivity.  So not only was your system damaged but you could not download a fix.

    Edit:

    Look on the birght side.  Microsoft released an update for the Windows 7 Phone that bricked one manufacturer's phones.  Windows 7 SP1 still leaves your computer usable.


    Tuesday, April 05, 2011 2:10 AM
  • Windows 7 SP1 still leaves your computer usable.
    in contrast to many thousands of applications running on pre Win 7 SP1 machines, which are suddenly not useable...
    Tuesday, April 05, 2011 1:44 PM
  • Did MS work on it 3 years ago? See http://blogs.office.com/b/microsoft-access/archive/2008/06/19/tech-talk-using-access-with-sql-server-panel-discussion-from-tech-ed-2008.aspx, search for "DAO is your friend".
    Except...when fixing ADO, they don't mess up ACE/DAO.
    Wednesday, April 06, 2011 2:29 AM
  • Did MS work on it 3 years ago? See http://blogs.office.com/b/microsoft-access/archive/2008/06/19/tech-talk-using-access-with-sql-server-panel-discussion-from-tech-ed-2008.aspx, search for "DAO is your friend".
    Except...when fixing ADO, they don't mess up ACE/DAO.
    Sure, I just thought they were going to mess up ADO three years ago. And that's why someone said "DAO is your friend", which, in relation with Win 7 SP1, could be translated as "ADO is your enemy".
    Wednesday, April 06, 2011 8:31 AM
  • So do we have a real fixes here other than :

    (a) use late binding (yucky)

    (b) build it on a machine without SP1 or Office 2010 on it ONLY

    (c) register old versions of MDAC on Win7 SP1 machines and wait for more bad news in the future

     

    This seems incredibly silly to me. I thought that breaking COM signatures (especially prominent ones) was typically avoided except by hacks and companies that thrive on generating maintenance revenue for their applications...not Microsoft.

    What gives here? Was it too hard to make a 64 bit friendly (specific) interface and have people recompiling with that one IF THAT'S WHAT THEY WANTED?

     

    :shakes head:

     

    :sigh:

    Thursday, April 07, 2011 1:45 AM
  • We have just released a new version of the KB: http://support.microsoft.com/kb/2517589 which provides a new workaround to the issue. This can be viewed as a temporary solution to the issue (for C++, VB6 and VB.NET customers only). Although this is temporary, this should work forever if you chose this workaround, since the downloaded typelib is basically the same as the one shipped in Win7 RTM (with LIBID changed, so you can see two entries in the "Add Reference" dialog). This is suitable for those customers who would like to use Win7 SP1 as a development platform.  

    Unfortunately, the workaround cannot work for VBA scenario.

    We understand this can still cause some inconvenience to customers since you need to change the referenced typelib, and this does not work for VBA customers. But this is the fastest solution that we can provide to temporarily resolve this issue. And we are still working on a longer-term solution which may take more time.

    Regards,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Thursday, April 07, 2011 2:21 AM
  • Ming,

    A MUCH better solution. THANK YOU!!


    "The right to be heard does not include the right to be taken seriously.” -H. Humphrey
    Thursday, April 07, 2011 2:46 AM
  • Can you tell us the status of the Access/VBA solution?  This is a real pain for our many clients!

    Bill


    BillDenver
    Thursday, April 07, 2011 3:04 AM
  • I am sorry, but we cannot disclose any product information / release date in such a public environment according to policy.

    But this is certainly one of our highest priority work item to figure out the longer-term solution. Meanwhile, VBA customers may want to use Win7 RTM as your development platform.

    Regards,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Thursday, April 07, 2011 3:49 AM
  • Meanwhile, VBA customers may want to use Win7 RTM as your development platform.
    How about a hotfix that simply backs out the MDAC update portion of SP1?  This is not the first time that a service pack needed a hotfix to reverse something.
    • Proposed as answer by saberman Saturday, April 30, 2011 11:48 PM
    Thursday, April 07, 2011 3:59 AM
  •  Meanwhile, VBA customers may want to use Win7 RTM as your development platform.

     Are you real?

    I've got dozens of customers who want to move to win 7 + office 2010 platform and I have to cool them down.

    The once that made it  without checking with me first now I have to fight with their SysAdmins to downgrade the windows to XP or win7 prior to sp1 and remove office 2010 and install 2007 instead. And of course SysAdmins say to my clients that my software is not good it won't work with the new computers, So "THANK YOU MICROSOFT".

    My guess my clients might start looking for other solutions soon.

    Why won't you take saberman   idea and make a  hot fix.

     

    Thursday, April 07, 2011 5:53 AM
  • As mentioned before, we are investigating all possible solutions to resolve the issue completely at a high priority.  We will study the pros/cons of all possible solutions. But it definitely takes time to figure out the final solution.

    For the moment, we can only provide a few workarounds that might not work for all people, but works for certain amount of people. We understand that this can cause inconvenience to other customers that cannot apply the workaround.

    Regards,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Thursday, April 07, 2011 6:07 AM
  • Meanwhile, VBA customers may want to use Win7 RTM as your development platform.

    Are you serious? Or is this just a joke? Why not simply revert ADO libraries and leave them untouched FOREVER?
    Thursday, April 07, 2011 6:47 AM
  • We have just released a new version of the KB: http://support.microsoft.com/kb/2517589 which provides a new workaround to the issue. This can be viewed as a temporary solution to the issue (for C++, VB6 and VB.NET customers only). Although this is temporary, this should work forever if you chose this workaround, since the downloaded typelib is basically the same as the one shipped in Win7 RTM (with LIBID changed, so you can see two entries in the "Add Reference" dialog). This is suitable for those customers who would like to use Win7 SP1 as a development platform. 

    I guess it should be mentioned that if you have some developers on Win7 SP1 and others on say WinXP, Vista etc etc and if you choose the new work arround you must install the Backcompat tlb's on all of your development machines, not only your Win7 SP1 machines otherwise when you compile your projects on those older OS's you will get missing reference errors.

    • Edited by Pawaw Thursday, April 07, 2011 9:38 AM
    Thursday, April 07, 2011 7:59 AM
  • Yes, this is TRUE. We think that developers (like you) can figure this out easily.

    Thanks,
    Ming.
    WDAC Team, Microsoft.

     


    Pak-Ming Cheung - MSFT
    Thursday, April 07, 2011 8:24 AM
  • We think that developers (like you) can figure this out easily.

    I think you should stop being condescending and amend the documentation for the kb.

    Thursday, April 07, 2011 9:05 AM
  • I am truly sadened that this has taken so long to resolve (and hasn't been resolved yet) But as a VBA / Office Developer I am supremely interested in a real fix for this problem in the mean time I have had no problems registering and using the old ado libraries on my target machines, after dumping SP1. Granted that isn't the best fix but its a fix.

    Please fix this asap, and I am happy at least that the WDAC Team is now actively working on a solution.

    David



    Thursday, April 07, 2011 3:04 PM
  • I am truly sadened that this has taken so long to resolve (and hasn't been resolved yet) But as a VBA / Office Developer I am supremely interested in a real fix for this problem in the mean time I have had no problems registering and using the old ado libraries on my target machines, after dumping SP1. Granted that isn't the best fix but its a fix.

    How does the changed typelib affect VBA code at all?

    Only compiled code where new IIDs unknown on pre-Win7-SP1 machines are built into the generated code does not work on pre-Win7-SP1 machines.

    Can VBA code be pre compiled as well?

    My understanding was that VBA code sits in document or template files as source code and will be interpreted on the target machine. So ADODB.Connection, Recordset and so on should always be resolvable as those type names exist in both the new and old ADODB type library.

    To me it seems that VBA and especially VBA of Office 2010 x64 was the reason of the type library change, so that e.h. RecordCount would be of variant type VT_I4 and not VT_I8.


    -- SvenC
    Thursday, April 07, 2011 3:18 PM
  • I am happy to also hear that a long term solution is being worked on.  COM 101: Do not change your GUIDS or program id's for backwards compatibility.  Someone at Microsoft forgot that simple rule.

    As one of the developers of a business application used by tens of thousands of users around the world, we will be watching this thread very closely.

    Friday, April 08, 2011 1:41 AM
  • Those who hang out here these days are developers who previously stumbled over the problem, damage already done. The evil in this issue is that developers out there that are still unaware of the problem, are (and will be) deploying "damaged" code as they upgrade to SP1, almost operating as viral agents. The only solution to stop this spreading is to remove the GUID change from SP1, eliminating the issue on future upgraded machines.

    Another mitigating solution (for the VB6 side) might be to add a severe compatibility warning when launching VB6 IDE on Win7 SP1.

    Of course, developer responsibility should always be to test thoroughly on the client OS before deployment. Most of us did not, Microsoft neither did.

     



    Friday, April 08, 2011 5:11 PM
  • This is becoming quite a pain...  Never thought to test everything that has worked for years!

    I now need to redo an upgrade for over 250 users after rolling back our development computers to pre-SP1.  We've spent hours researching why they were no longer connecting to the database!!! 

    What a waste of everyone's (including MSFT) time.

    Please fix this downgrade now. 


    BillDenver
    Saturday, April 09, 2011 3:15 PM
  • News? Just to remind you there are VBA developers still waiting for solution

     

    By the way

    Have any one information about developing addins for Word Web App skydrive - I know wrong forum :-)

     

    Monday, April 11, 2011 6:30 AM
  • Hi everyone,

    I also noticed that the file functions in VB6 dont work if you use drive letters on the network path.
    Just tested Open File and Dir functions.

    I tested to bring back the old msado26.tlb and everything works ok.

    Example Dir("P:\*.txt") dont work (no results). Dir("\\Projects\*.txt") works.

    Anyone else discovered this problem?

    /Rille

     

    Monday, April 11, 2011 1:01 PM
  • Hi everyone,

    I also noticed that the file functions in VB6 dont work if you use drive letters on the network path.
    Just tested Open File and Dir functions.

    I tested to bring back the old msado26.tlb and everything works ok.

    Example Dir("P:\*.txt") dont work (no results). Dir("\\Projects\*.txt") works.

    Anyone else discovered this problem?

    /Rille

     


    Are you sure that bringing back the old tlb file is the only difference in your case?
    Could not think of any way how a changed type library would affect a VB6 built in function.

    My guess is that due to UAC you have different mappings in your user and admin session.

    So when you add a mapping as normal user your app running elevated does not see those mappings.


    -- SvenC
    Monday, April 11, 2011 1:06 PM