Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

Checking if MSDE is already there


4 replies to this topic

fish

fish
  • Members
  • 15 posts

Posted 02 May 2002 - 10:30

Hi,
I need to check if MSDE is installed, and if not, install the merge modules.  I've got the merge modules, but how do I check if MSDE is already on the system?

Thanks

John

Stefan Secker

Stefan Secker
  • Members
  • 46 posts

Posted 07 May 2002 - 10:54

Quote (fish @ May 02 2002,11:30)
Hi,
I need to check if MSDE is installed, and if not, install the merge modules.  I've got the merge modules, but how do I check if MSDE is already on the system?

Thanks

John


Found this on MS' website.
http://msdn.microsof...rary....sol.asp
Maybe this helps, i'm still fighting the MMs. I guess
i will rather use a customized MSDE sample MSI and a nested installation via CA instead.

HTH,
       Stefan

fish

fish
  • Members
  • 15 posts

Posted 07 May 2002 - 12:31

Thanks Stefan,
There was a thing on there that showed how to check the MSDE/SQL Server version.  I think I'll probably check this, and if it returns blank, assume it's not installed.

Can you get CA's to run reliably?  I'm having all kinds of problems with them.

Thanks

PS: what kind of issues do you have with merge modules?  They seem to work for me.



Stefan Secker

Stefan Secker
  • Members
  • 46 posts

Posted 10 May 2002 - 08:57

Quote (fish @ May 07 2002,13:31)
Can you get CA's to run reliably?  I'm having all kinds of problems with them.

Thanks

PS: what kind of issues do you have with merge modules?  They seem to work for me.


In general i think this CA and MM stuff is a pain in the @$$. I still wish i would have kept IS 5.5  ??? .
Anyway, most of the time it's a question of time until the trial and error way solves the CA problem. Unfortunately time is always short.

MSDE CAs:
I didn't manage to install the MSDE MSI as nested installation yet. Still getting strange errors there, but i'm not sure whether i use the CAs in the correct way.

MMs:
It's a problem with the new IS version. You can read it in the topic MSDE MM again, Error with ISDev 7.03 ?.

To get the MSDE thingy working properly, I think I will downgrade to 7.02, if can't get the CAs working today, although this back and forth really annoys me.

Cheers
          Stefan

fish

fish
  • Members
  • 15 posts

Posted 10 May 2002 - 09:59

Quote (Stefan Secker @ May 10 2002,07:57)
MSDE CAs:
I didn't manage to install the MSDE MSI as nested installation yet. Still getting strange errors there, but i'm not sure whether i use the CAs in the correct way.

MMs:
It's a problem with the new IS version. You can read it in the topic MSDE MM again, Error with ISDev 7.03 ?.

To get the MSDE thingy working properly, I think I will downgrade to 7.02, if can't get the CAs working today, although this back and forth really annoys me.

Cheers
          Stefan

CAs:
Wise Tech Support (I use Wise For Windows Installer 4.02) say try putting an action just before or just after the InstallFinalize action (I think it's probably called something similar in IS, since the MSI Script WFWI uses is just a representation of the sequence tables).  I've only tried an action just before, and it worked.  Although that was only getting to open NotePad to see if I could do it.

MSDE MM's:
They don't detect a previous install of MSDE.  somebody suggested using a named instance.  I also found this on that site you gave me:

<--- excerpt from MSDN
Detecting and Interpreting Database Server Build Numbers
A simple way to check for the existence and version of a database server installation is to determine if the CurrentVersion Windows registry key exists and examine its contents. This key resides in different locations of the registry depending upon the version of the database server that is installed on the system.

The CurrentVersion registry key for SQL Server version 4.21 resides in the following location:

HKLM\Software\Microsoft\SQLServer\Server\CurrentVersion\CurrentVersion

The CurrentVersion registry key is a string that contains the version number for Microsoft SQL Server. For release 4.21, the string follows the following format:

NT <Major Version>.<Minor Version>

For example, the shipping release of SQL Server 4.21 for Windows NT is "NT 4.2."

The CurrentVersion registry key for SQL Server version 6.0 and later and MSDE 1.0 can be found in the following location:

HKLM\Software\Microsoft\MSSQLServer\MSSQLServer\CurrentVersion\CurrentVersion

The CurrentVersion registry key is a string that contains the version number for the database server. For SQL Server 6.0 and later and MSDE 1.0, the string follows the following format:

<Major Version>.<Minor Version>.<Build Number>

The official build number for SQL Server 7.0 and MSDE 1.0 is "7.0.623." Some releases of MSDE 1.0 that shipped with Microsoft Office 2000 Developer Edition may be improperly identified as build "7.0.677" in the registry. This anomaly is corrected on any MSDE 1.0 installations that have been upgraded with SQL Server 7.0 Service Pack 1 or 2. The techniques described in this section are implemented in the CheckSql and CrackSqlBuild routines in modMain.bas.

To detect the SQL Server service pack level, check for the existence of the following Windows registry key and examine its contents:

HKLM\Software\Microsoft\MSSQLServer\MSSQLServer\CurrentVersion\CSDVersionNumber

The CSDVersionNumber value contains the service pack level stored as a DWORD (for example, "100" indicates Service Pack 1, and "200" indicates Service Pack 2).

Detecting the SQL Server 7.0 or MSDE 1.0 Package Type
In some situations, just knowing the build number of the installed database server is not enough. The term "Package Type" refers to the actual stock-keeping unit (SKU) that was used to install SQL Server or MSDE. It may be important to know the package type of the database server installed on the system in order to determine its capabilities.

There are two techniques for determining the package type for an existing database server installation. The recommended technique is to interrogate the return value of the SQL-DMO IsPackage method. This approach is the only way to conclusively detect whether SQL Server Desktop Edition is installed. However, it does not distinguish between different variants of MSDE. This technique is demonstrated in the GetSqlPkgType routine in modSqlDmo.bas.

The package type can also be determined by calling the QueryValue function in a dynamic link library named SQLBOOT.DLL, which is located in the BINN subdirectory of the database server installation directory.

The C language declaration for QueryValue is as follows:

DWORD WINAPI QueryValue(DWORD dwSetting);
typedef DWORD (WINAPI *LPFNQUERYVALUE)(DWORD); // QueryValue function pointer

To determine the package type of the installed database server, call the QueryValue function with the dwSetting parameter set to the hexadecimal value 0xD7887E1E. The function will return a DWORD value that can be used to determine the package type as defined in the following table.

Table 3. Package types returned by SQLBOOT.DLL

Package Value Description
PACKAGE_OFFICE 1 MSDE 1.0 Office 2000 Release
PACKAGE_STANDARD 2 SQL Server 7.0 Standard Edition or SQL Server Desktop Edition
PACKAGE_ENTERPRISE 3 SQL Server 7.0 Enterprise Edition
PACKAGE_MSDE 4 MSDE 1.0

The QueryValue function returns PACKAGE_STANDARD for SQL Server 7.0 Desktop Edition installations. If you have detected a SQL Server 7.0 Standard Edition installation, it is safe to assume that it is actually Desktop Edition if the operating system is Windows NT Workstation, Windows 95, Windows 98, or Windows 2000 Professional. Standard Edition can be assumed if the operating system is Windows NT Server. It is possible to install SQL Server Desktop Edition on a Windows NT or Windows 2000 server. The only negative ramification of a mistaken assumption that a SQL Server installation is a Standard Edition package when it is actually a Desktop Edition package is performance-related, because Desktop Edition does not scale beyond five users.

Automating Database Server Installation
The installation executable for Microsoft SQL Server 7.0 and MSDE 1.0 Office 2000 Release is named Setupsql.exe, and was developed using InstallShield from InstallShield Software Corporation. SetupSql operates in both an interactive mode where a user responds to several dialogs presented by an installation wizard, as well as an unattended mode where the input for each dialog box in the wizard is read from a special text file called a "Setup Initialization File," which will be discussed in detail in a subsequent section of this document.

Normally, SetupSql is used to install a database server on a local machine. SetupSql supports the installation of SQL Server 7.0 on a remote Windows NT or Windows 2000 system, provided it is the same processor platform as the system running SetupSql. However, the techniques for automating remote installations are not currently supported. If you need to automate a remote installation, refer to Microsoft Support Knowledge Base article Q231735 entitled, "INF:SQL 7.0 Remote Unattended Install".

MSDE 1.0 shares a common installation code base with SQL Server 7.0, but enables single-file distribution of MSDE by way of an InstallShield "PackageForTheWeb" file that is digitally signed by Microsoft Corporation. This is a self-extracting executable that packages all of the files needed to install MSDE (including SetupSql) into a single file.
--->

maybe the easiest way to do it is to have it search for a registry key (version number would do it, and this will allow you to check if you have the correct version as well.  If you have the correct version, don't install MSDE), then stop if the key comes up with something.

BTW, my rolling back problem may not be the merge module, or my installation.  It could be the machine, as I tried to install SQL Server 2000, just to see if it would, and it didn't.  Said the OS wasn't supported.  Well, it was NT 4, Service Pack 6.  According to our IT guy, that should be enough.

Cheers

John