I had originally installed SQL 2005 Express on my laptop, and something happened during the installation and it got corrupted. I was unable to uninstall, whether I used Add/Remove programs, ran setup.exe ACTION=uninstall from the command line while in the SQL root path, even if I used msicuu2 and msizap to look for the GUIDs associated with SQL 2005. Nothing worked. I thought installing SQL 2008 Express might “fix” or overwrite something and then get me the latest version to play with anyway. Couldn’t have been further from correct. Now I had two corrupt installations and no way to remove either one.
After much research online and trial and error, I was at a point of giving up and wiping the hard disk. I HATE wiping the hard disk for something like this, I feel like I failed somehow. Outside of serious corruption there’s always a way to fix something software related, right? Well, I stumbled upon an MSDN posting later today where users were having similar issues, and one person suggested removing the following registry entry:
HKLMSOFTWAREMicrosoftMicrosoft SQL Server90
So, I went back into Add/Remove Programs, removed all things SQL, stopped all SQL services and set them all to Disabled, restarted the computer, made sure visual Studio 2008 had SP1 installed (because once before it barked at me saying that was required) and tried the install again. Voila! Everything installed perfectly except Full Text Search. Since I’ve been without a local database on my development machine for the past two years, Full Text Search is the least of my problems right now! I’m just thankful I finally have something to work with.
So, if anyone is having problems with the Express SQL versions, or something similar is happening that is preventing you from upgrading to either SQL 2008 Express or SQL 2008 Enterprise or Standard, check out this MSDN thread and see if it helps you:
I recently ran into a problem where I needed a Silverlight slider control pre-populated with a specific value when the page loaded, but if you use the slider`s ValueChanged event in the code behind file, it dies. Why? Because as the page loads and initializes, the code behind is trying to run and the slider control hasn`t finished being created yet. Putting the values I wanted them to start at worked fine, as long as you put them after the Initialize(); call in Page_Load, but I still wanted the ValueChanged method to fire when the value changed on the slider. Here`s what I did to make sure the ValueChanged method fires and I can still pre-populate the slider at initialization:
Slider slider = (Slider)this.FindName(“slidername”);
if (slider == null)
// Do something
The first line there looks to make sure the control was created before even continuing. If it exists, it then will allow whatever you want from it without throwing an error.
I recently encountered an issue where I hadn’t created an SSIS package in a while, and when I opened BIDS 2005 and said “Create New Project”, after naming the project and proceeding it barked at me, saying “Failed to save package file with error 0x080040155 ‘Interface not registered’. Turns out somehow my MSXML assembly files got unregistered. The way to fix this that worked for me, was to re-register msxml3.dll, msxml4.dll and msxml6.dll. Some said to just do 3 and 6, which would probably work, but it doesn’t hurt to register all three anyway. That did the trick!
So, for the past few months a DBA and I were trying to figure out why all of our SSIS packages, connection strings and data sources all work fine on Server 2003, SQL 2005 and of course in dev, but not on our production SQL 2005 server. After extensive research (which was probably right in front of our faces the whole time) we stumbled over the following KB article:
Which very briefly explains how the OLE DB and ODBC providers are only available on 32 bit systems, and our production SQL 2005 server is 64 bit. Since 64 bit performs so much better, and SQL is a resource hog to begin with, this seemed like the best solution. Then when we installed ILM 2007 (64 bit) and wanted to connect to the database (also 64 bit), and things kept failing, we’d beat our heads into the wall trying to figure out why. According to the KB article, there is no plan to support these providers in a 64 bit environment, and the best solution is to just emulate a 32 bit environment, such as run the application in 32 bit mode. Not that easy when you’re custom-writing interfaces, applications and queries. However, thanks to my co-worker’s friend he pointed out a way to run an SSIS package on a 64 bit server and make it think it’s 32 bit!
While creating the package in VS2005, go to Project->Project Properties. Look for the element called “RUN64BITRUNTIME” and change it to False. Then save and deploy the package as usual. Finally, you cannot execute the package from the UI or even from a SQL job. You’ll need to execute it from the command line using DTEXEC utility. To automate this, use a SQL job to call the DTEXEC utility command, either through xp_cmdshell or a batch job. More details can be found by reading this article from SQL Server 2008 Books Online.
So, there is a workaround to this apparent roadblock. The best part of all of this? There is allegedly support for these two providers in SQL 2008. We haven’t had a chance to test this yet, but that explains why they’re not supporting 64 bit versions in SQL 2005….just get SQL 2008!