10 replies to this topic

[Josh Luth]

I replace my MSDE SP2 msms with the MSDE SP3 msms. Now when I run my upgrade to my old software (I am doing an upgrade, by reinstalling), my version of MSDE is unchanged. What am I doing wrong??

[Stefan Krueger]

What's in the log? Does your setup complete successfully? Did you try a patch?

[Josh Luth]

The setup completes successfully. I didn't try just a patch because there are some custom actions that I call to run some sql scripts to update my database as well. I don't think these would run in a patch. The log is long... I didn't see any errors in it. Not sure how to get it to you since I can't attach here.

[Stefan Krueger]

Custom actions would also run in a patch.
You can zip it and upload it to your server, then post the URL here.

[hyper]

Anyone have an idea of why they changed the attributes on the DbMaster..., DbData.. and DbModel.. components between SP 2 and SP3 ? They are now set to 16 (permanent) and this created all sorts of problems for me on my test machines when I installed my installation the second time and the master.mdf etc. files was already there.

Einar

[Stefan Krueger]

Microsoft just clarified that in order to update an existing MSDE instance that you installed using the merge modules you must use a patch (.msp). Updating using a full install .msi (running with REINSTALLMOE=vomus REINSTALL=ALL) will not update MSDE. That's because the merge modules detect that MSDE is already installed and do nothing.

[Josh Luth]

Quote (hyper @ Jan. 31 2003,07:46)

Anyone have an idea of why they changed the attributes on the DbMaster..., DbData.. and DbModel.. components between SP 2 and SP3 ? They are now set to 16 (permanent) and this created all sorts of problems for me on my test machines when I installed my installation the second time and the master.mdf etc. files was already there. Einar

I noticed this too.... do you suppose we can change these back an d not have problems??? what was the original value?

[hyper]

Quote

do you suppose we can change these back an d not have problems??? what was the original value?

The old value was zero, and I'm changing it back. Can't see any reason why these files should be left behind when I uninstall.

Einar

[jfchickimon]

First of all, to clear the air, I hate this stuff.  Okay...

Stefan, you say:  You cannot update MSDE using a full install package (running the .msi with REINSTALLMODE=vomus REINSTALL=ALL). This would not update the MSDE files. Instead must use a patch (.msp) file, or a Major Upgrade, which in essence uninstalls the old version and then installs the new version. Beware that a Major Upgrade may also delete user data.

I say: I have been trying to create a minor upgrade for a week, and for the most part it has been successful.  I get annoying "Unable to run script files" errors occasionally, and I still want to determine the cause of those.  But otherwise, all indicators show that the upgrade takes place - version .760 for sqlservr.exe, ssmslpcn.dll, dbmslpcn.dll, and ssnetlib.dll, and using OSQL (select @@version) shows version .760. (are there any other ways to verify the upgrade was successful?).  The only question is that CSDVersion in the registry still shows .534 (our base install was MSDE 2000 SP2).

When I tried a major upgrade, because you said it was necessary, I get a instance name clash and the install aborts.  Sounds like the MSDE merge modules can't figure out that I want to uninstall and reinstall the existing instance.

Lastly, the Microsoft KB article 317328 says that you can do a minor upgrade:  You can consider a minor upgrade in which you upgrade the MSDE 2000 merged modules to a service pack level. The upgrade changes the package code and the product version for a package that ships as a full product installation package or as a patch package.

So what is up?!  Can I do a minor, or must I do a major?  If so, how to do a major?

Any assistance would be greatly appreciated.  The last week of meddling with this stuff has been a drag.

[Josh Luth]

I think I may have figured out how to do mine. I am doing an Uninstall and Re install to do my upgrade. When I installed initially the mdfs that will contain the user data were installed as permanent so I won't be losing any user data.

The problem you were having with the name clash would be because of where you have your uninstall sequenced. It needs to come after Launch Conditions but before AppSearch (I think). At least that is how it is working for me. I am following the logic in  this article to do the upgrade.

This is a big 'ole pain in the A$$ but it seems to be working at least and that is what I need.

[Stefan Krueger]

My message was based on the reply from Yuhong Li (SQL Server Development Team [MSFT]) to Josh's question in the microsoft.public.sqlserver.msde newsgroup, which is as follows:

Quote

If you integrate MSDE SP3 MSM, you get a clean build MSDE+SP3. That means you have to  install this build on a machine which doesn't have any MSDE, then you will have MSDE SP3 installed. The log file suggested you run MSDE SP3 build on a machine which has MSDE SP2 already.  In this case, MSDE thinks you have installed MSDE already with the following message in the log file:    .......   MsiEvaluateCondition for SQLMSDEInstalled returned TRUE   ....... So it didn't update any bits, that's why you still see your SP2 installed. In the situation of upgrading SP2 -> SP3,  you need to run Windows Installer's "patch" (*.msp), not msi. The patch is built from the original msi against the new msi. Microsoft provides MSDE patch for MSDE SP3. You need to create the patch for your own msi if you do have the situation to upgrading SP2 -> SP3.  Usually I would suggest to remove MSDE+SP2, then install the clean new MSDE+SP3 from your msi, so you don't need to create the patch.

I haven't actually tried it, so Yuhong Li might be wrong. Maybe you could post your observersation in the above mentioned newsgroup to see what Yuhong Li has to say about it.