Windows 7 service pack 1 components

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. Can someone from Microsoft please comment on whether a special license is needed to redistrute the MDAC package?

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

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.

Well David you're not alone in this, they'll have to sue some developers just for losing our jobs, and companies that lost their client's, but they be happy for opening new development projects for the existing solutions that where broken. Maybe you are seeing a different problem here? 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. I will definately agree there, i have developed on every version from to and its appalling how one version will introduce new features only to break existing features like the package wizard in not being able to include directories but 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 's Data Access Pages? What a joke 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 bucks per computer on the standard office, then i said to myself yeah are you really sure thats going to work correctly 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.

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. 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. 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. 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 What gives here?

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.

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. This is a real pain for our many clients! But this is certainly one of our highest priority work item to figure out the longer-term solution. Are you real? 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 and install instead.

My guess my clients might start looking for other solutions soon. Why won't you take saberman idea and make a hot fix. As mentioned before, we are investigating all possible solutions to resolve the issue completely at a high priority.

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. Granted that isn't the best fix but its a fix. My understanding was that VBA code sits in document or template files as source code and will be interpreted on the target machine.

Connection, Recordset and so on should always be resolvable as those type names exist in both the new and old ADODB type library. I am happy to also hear that a long term solution is being worked on. 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. 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. Of course, developer responsibility should always be to test thoroughly on the client OS before deployment.

Most of us did not, Microsoft neither did. 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 users after rolling back our development computers to pre-SP1. We've spent hours researching why they were no longer connecting to the database!!! 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 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. 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. I have no idea why it does not work. It works fine on my Win7 SP1. I am using the following code snipplet:. Please verify a few things: 1 Does it works with the original 6.

Since VB6 is out-of-support for a long time, it might have some other bugs inside. It is kind of shipped "as is", and you might need to spend more effort to troubleshoot any VB6 issue yourself.

You must address a mapped network drive. Not local harddrives. I would be very happy if this problem only exists on my computer :. I see the same behaviour when debuging, however if I compile the example into an exe and run it then it works fine. I agree with SvenC I dont see how adding typelibs that are not even referenced in the example can cause this issue. Thanks Pawaw to dig out this.

Thx Pawaw Then I'm sure the other crazy stuff about the tlb file will be the same as mine if you try that out. I dont have a clude why this tlb have this effect We have a lot of VB6 code on my company and this is a annoying bug but by using a old tlb everything is fine for now.

Soon there will be only C to worry about since the VB6 code is beeing converted as we speak. In my program it can connect now to my. I've done that article id : says. Could you share your code snipplet? What is error 13 any error message, which component returns that error? I was just bitten by this change! Oh, Microsoft you sure keep me occupied!

After a few hours of investigation I realized this was the problem. Don't know if this solution will come back to bite me in the future, but I'm going with this for now. Compiled with it it goes ok in Windows 7 SP1. We are intending to change our client environment soon and I had done some initial testing of some of these apps using the same executables with a Windows 7 bit RTM client with the same Win backend late last year. All appeared to be fine. This week thinking it would be a sure thing I started testing one of these using Windows 7 SP1.

To my surprise the app had barely started and I got an 'automation error - element not found'. I checked that I had not made any installation mistakes.

This references the same library but only uses it to allow a recordset to be passed between the client and server it is never actually used. As I mentioned we have several significant applications built on this architecture so this could causes us very major problems. The client application is just a form with two buttons that contains the following code:. In the first two cases clicking either button displays the expected dialog.

On SP1 the 'automation error - element not found' message appears in either case. The first call does not even involve an ADO parameter but from earlier posts I am guessing that the mere presence of the ADO library reference is causing the problem. Please can anyone explain what is going on here, whether this is related to the other incidents described in earlier posts, and, hopefully, what we can do to workaround the issue. Again, which platform have you used to compile your client app?

All the code was compiled on an XP machine as this is where the existing application code would have been compiled. Quite possibly this is another issue, but uninstalling SP1 solves it so it is an SP1 problem. I thought people on this thread might think this relevant as it may share the same root cause. Please respond to it there.

Am i the only person wondering if microsoft did this on purpose to break vb6 on purpose to force everyone to swtich over to vb. Of course that would work for microsoft in the long term since C and asp. No David, you're not the only one. I've pretty much come to the same conclusion - the ADO break hidden in Win 7 SP1 was a back door way of pushing developers toward the.

Net world. MS had to have known what was going to happen, even if they were surprised by the backlash. It was just too blatant to be otherwise. As I've pointed out before, the clever part was that they did in such a way as to ensure that it would be the sys admins and developers who got slammed when the inevitable problems occurred. We are in effect Microsoft's "human shield".

When will there be a VBA fix for this mess??!! I mean a real fix - not late binding or uninstalling SP1, but a fix that lets us keep our OS up to date and still provide good products to our customers. These projects bind to specific versions of ADO i. Not late binding. We have partitially moved to. NET so we access these via interop files. The Web Service are built in. The product is built on Windows and has been working on Windows R2 for some time now.

Once SP1 is installed, the Web Services continue to work without any issue. The error returned when attempting to call a method of the COM interface is:. Element not found. To determine what was causing the issue, I installed SP1 on a development machine and tried to rebuild the. NET project. This fails with the same error above. If I try and look at the methods available in the Visual Studio Object Viewer I see the interface but it has no methods. I then open the VB Component and try to rebuild it.

The component is built with Binary Compatibility enabled. The attempt to rebuild it fails with the following error:.

The only way I can get around this is to disable the binary compatibility and rebuild the project. This works and now the. So are we being forced to break binary compatibility as well? What I can't understand is why this is only an issue for the projects with interops to methods returning ADO objects? Not sure how to proceed but for now we cannot support this service pack.

Need to find a solution that allows us to build on Windows and work on all versions of Windowsd including systems with SP1. Can someone edit wikipedia? I especially like the sentence "Microsoft has provided solutions to work around this issue". Perhaps it should read: Microsoft has provided solutions to work around this issue but those 'fixes' only addresses a small percentage of applications and still leaves VBA developers in the Cold with no fixes after 2 months, and having had this exact problem reported after beta testing of sp1.

Well i think anyone could cite this article as your source for the above statement. Makes me wonder if MS is the one who added that convinient line of falsehood.

I had the problem where one of my VB6 programs compiled on my Win7 SP1 64Bit laptop and run on a Win server blew up with a error on the following statement:. I installed the tlb's as per KB on that laptop, set the reference to the backward compatible tlb in that VB6 program, and recompiled it. The resulting exe will run on any machine on which I try it.

Thanks for your efforts to help resolve this issue. I appreciate that you are the bunny in the middle here. Try to remember that people's rants here are not directed at you personally. Sadly, Microsoft has left you here to face the flak.

Anyway, does not resolve the problem adequately for us. The BackCompat library lists the Recordset. RecordCount property as restricted for VB6. This is a change from the original. TLB, and effectively renders the BackCompat library incompatible. We successfully resolved the issue by uninstalling Windows 7 SP1. We have advised our customer base approx sites, avg 4 PCs per site that Windows 7 cannot be considered a reliable product at this time.

We have recommended that they refrain from any further Microsoft purchases until Microsoft adequately address issues related to their testing procedures, and have cautioned them that Microsoft updates may indiscriminately render other software products unusable. The download link will be removed in a few days and the KB will be slightly modified with a warning message. Customers should not download the original KB. If you have already downloaded the KB, we suggest you to uninstall the KB first.

Sorry for any confusion and extra work that you have already spent on this issue. We will release a new KB later. At that time, we will take care the Win7 SP1 customers as well. As mentioned above, I cannot communicate any technical detail or date of our plan, sorry about that. But this is still our top priority work. The link you provided above goes to the hotfix for the 64 bit issue and says this fix is in Windows 7 SP1. Are you saying Windows 7 SP1 will also be removed and replaced?

Do you mean there will be a fix that doesn't break existing applications or will there simply be a warning that SP1 can break existing applications. Please clarify. Thanks for your response Ryan. Yes that was going to be my next attempt; however I see posts here that suggests possible new issues using the BackCompat ADO.

Waiting to hear what WDAC team are now planning. I've been contemplating this issue overnight, and there appears to be some validity in the underlying reasons for deploying kb Perhaps an easy solution would be to deploy the altered. This would ensure that it does not break backwards compatibility for ADO2. I understand that everyone would like to know what we are going to do. NET and some other dimensions, etc.

Therefore, it is not good to share some prelimitary information here - otherwise, it just confuses people without much benefit. However, we will definitely consider all different scenarios not only about backward compatibility but also the ongoing dev experience. But at this point, there is simply no solution that can work for all scenarios. Therefore, we can only pick the one that cause the less pain to customers. NET are basically not supported; but we don't want to stop its working on the new OS because of this issue, although it may not work because of other issues.

On VB. Anyway, this is a little confusing because the thread originated from a concern of using unmanaged VB6 code and the breaking change in ADO. There is also an ominous warning that perhaps the VB6 runtime will not be supported in the new OS Windows 8 , but I guess we'll have to see about that. I was just chatting with a co-worker today about this debacle and I think much discomfort could of been avoided and time saved if VB. NET wasn't such a huge leap in technology.

That is, if the path from VB6 to VB. NET was simply a few clicks and you were up and running. Alas, it is not quite that easy But MS seems to have been a victim of their own success with VB6. It was just too darn easy to make applications. Oh well So, we have just finished the investigation of this issue. Therefore, the compiled application will reference to the new IID. Hence, it cannot work under downlevel platforms. The problematic application is referencing the typelib called " Microsoft Jet and Replication Objects 2.

It is a typelib embedded inside msjro. If you use the OleView. Whenever it runs on downlevel OS e. Could you explain more about "restricted for VB6"? What is the actual error you encountered in your development and how to reproduce this issue? I don't know about you guys, but I am just sick to death of this nonsense about dropping support and compatibility for VB6 now the redheaded step child!

It just proves to me that Microsoft doesn't give a rip about anyones code or customer base or what it costs to convert code from VB6 to. They made it more evident by changing GUIDS they promised would never change and breaking their own rules! I have millions of lines of VB6 code and components.

MS, you might have the resources to move from one platform or paradigm to another but MOST of us don't! Your moves in this matter just show total disregard for companies and developers who have have spent many, many years using your development platforms and have millions of man hours and lines of code, which we're just supposed to give up? Someone else pointed out that MS could have made a path for upgrading code from VB6 into the. NET platform and on, but no, they want to try and force everyones hand to move and fix what "aint" broke.

If had any other choice I would move away from Microsoft products, just based on the way you handle your customers. Yeah, I know all you. NET wizards are going to flame me for this but you guys obviously have resources that most of us don't. I have nothing against. NET except there was no upgrade path and you decide you are arbitrarily going to dump VB6. Has MS ever polled their developers to get an idea whats out there? Obviously not! If they had any idea how much VB6 code was out there they would have made a way to easily port the code to the next level or taken a different approach.

Net and ADO. Net and SMO. Plus we keep thinking that these programs are at end of life but then we get another order for them. In these programs we use the Recordset. RecordCount extensively in the VB6 code. We changed the reference to the BackCompat tlb library and, so far, our code runs fine on computers that are not running Win7SP1.

Vb net is a completely different language from vb 6 and is moving closer to C every day. I expect vb net will be the next dinosaur to get the cut. VB6 unfortunately is going to go away. It was a great language and I still have one program written in it that I have to support until at least Windows8. I dropped the other 6 programs that were in vb6 because I didn't want to support or sell something that will be obsolete in a year , maybe two?

My income dropped too but I guess I should have seen the writing on the wall. I appreciate all the time you've been putting into this issue and your willingness to communicate what you can. I wish I felt the same way about the company you represent. My question is, how much longer does this really have to take?

How much more "investigation" is necessary? This has been going on for months now. There are thousands of developers who were sideswiped by this and are struggling to maintain credibility with clients. What's wrong with Price's idea of issuing two different libraries so we can select as needed? I have not received any emails "yet" from customers who might have installed service pk 1 on Windows 7 and am not sure what to tell them if the vb6 program I sold them no longer works.

It would be upsetting to say the least if they start to request refunds for an issue that I have no control over. My business is too small to even consider that and I basically will be OOB Even though I have not received any emails asking for refunds for this issue, it's still possible that potential customers are getting these issues and are just not buying my software.

I hope an answer is found soon, telling customers to uninstall a service pack is difficult. Most don't even know how to get to their control panel.

Then there is the issue of what might have been installed after the SPK1 was installed and will now also be broken. The content you requested has been removed.

Ask a question. Quick access. Search related threads. Remove From My Forums. Answered by:. Archived Forums. General Windows Desktop Development Issues. Sign in to vote. Friday, February 18, AM. In the preview build, what we have done are: - Pull out the 6. Thanks, Ming. Monday, September 19, AM. Could you please check if using the approach in that KB article can solve your problem?

Saturday, February 19, AM. Please escalate this issue because of the reach of breaking code. Just to make this clear: this is not a VB6 only issue. Further to my comment above. I hope this help you isolate the problem quickly. Saturday, February 19, PM. 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.

Sunday, February 20, AM. Please, can anybody from Microsoft comment on this breaking change and how to go along with it? If you have to re-compile your application on SP1, there are several workarounds: Request a package of KB and install it on your customers' machines. Re-compiled application should work after the package is installed.

Keep an old version of ADO typelib i. Hope these help. Monday, February 21, AM. Thanks, Shuhai Shuhai Shen - I love programming, travel and photographing. Monday, February 21, PM. Shuhai Shen - I love programming, travel and photographing. Tuesday, February 22, AM. 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.

Seems to me that all COM specialists either have slept, left or are too way up in the cloud. Tuesday, February 22, PM. Hi Alan, yeah, taking ownership and replacing ACLs to replace files is a bit time consuming if done manually on several machines Hi Neil, Could you please share the project by SkyDrive or other file sharing service?

Hi Rene, I guess you use import to generate the wrapper classes? Thanks for the suggestion! Wednesday, February 23, PM. Maybe a better solution would be to only change the x64 type lib and leave the x86 one alone. Did you discuss this solution as well? If you have to re-compile your application on SP1, there are several workarounds: Workarounds?

What on earth happened to backward compatibility? A total failure!!!!!! Thursday, February 24, PM. The reference wizard does this in the back end. Friday, February 25, AM. Microsoft has recently released the official service pack for the Windows 7, called the Windows 7 Service Pack 1 or SP1. Installing SP1 will help you prevent any security , functionality or compatibility related issues which you might be facing because of not having updated your Windows OS software.

Now click the Install updates button and it will take care of the rest of the procedure, it will download the required components of Windows 7 SP1 and will automatically install and re-start your Windows 7 PC.

This is the easiest and fastest way of installing Windows SP1. On this page you will see a validation section, click continue for validating your Windows 7. Thank you! This thread is locked. You can follow the question or vote as helpful, but you cannot reply to this thread. I have the same question Report abuse.

Details required :. Cancel Submit. In reply to Deathless1's post on February 25, Deathless1, I think the next logical step is to perform an InPlace upgrade. Keep in mind: An in-place upgrade is the final alternative before you have to reinstall the operating system.

In the Setup window, click Install Now. In the Programs list, click Setup.