Здравствуйте, sasha, Вы писали:

S>Всем привет. Возникла необходимость определения наличия на машине установленной платной версии SQL Server 2008 (любой, отличной от Express). Погуглил, но четкого ответа не нашел. Может кто сталкивался и может помочь?

SM>Можно через WMI попробовать. Вот здесь есть пример для 2005-го сервера, для 2008-го должно быть аналогично.

WMI в инсталляторе — (IMHO) — эТТо несерьезно (c)
Можно просто сделать еще один шажок с реестром, и все будет окей:

Set sh = CreateObject("WScript.Shell")

' читаем список имен установленных инстансов
instances = sh.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\InstalledInstances")

' пробегаем по списку и для каждого инстанса определяем его тип (EditionType)
For Each instance In instances

    ' получаем ключ реестра в котором находятся данные для этого инстанса
    instance_key = sh.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\Instance Names\SQL\" & instance)

    ' читаем эти данные
    EditionType = sh.RegRead("HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\" & instance_key & "\Setup\EditionType")

    WScript.Echo "Instance=" & instance & ", EditionType=" & EditionType
Next

Instance=SQLEXPRESS, Edition=Express Edition
Instance=SHAREPOINT, Edition=Express Edition
Instance=MSSQLSERVER, Edition=Developer Edition

N.B. это работает для SQL 2005/2008, для SQL SERVER 2000/MSDE 2000 и ниже это не сработает — там (AFAIK) SKU вообще в реестр не пишется.
Впрочем, WMI для этого случая тоже не сработает, думается здесь возможна только лобовая проверка на то что продукт установлен по ProductCode (то есть по GUID)

Здравствуйте, bnk, Вы писали:

bnk>WMI в инсталляторе — (IMHO) — эТТо несерьезно (c)
Почему, если не секрет?

bnk>Можно просто сделать еще один шажок с реестром, и все будет окей
Шажок не так прост, как кажется на первый взгляд. Например, если на 64-битную версию Windows поставить 32-битный SQL Server, то информацию о нём нужно искать в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server, а не в той, которая используется в примере.

bnk>N.B. это работает для SQL 2005/2008, для SQL SERVER 2000/MSDE 2000 и ниже это не сработает
Автор просил для 2008-го, так что это не критично. Но для старых версий, действительно, всё по-другому.

Здравствуйте, Sergei MO, Вы писали:

SM>Здравствуйте, bnk, Вы писали:

bnk>>WMI в инсталляторе — (IMHO) — эТТо несерьезно
SM>Почему, если не секрет?

Претензии к WMI примерно такие
Ну например, вдруг WMI вообще выключена? И такое бывает =)
Далее, WMI, это же типа скрипты (=CreateObject, COM). Некоторые тупые антивирусы на скрипты в инсталляторах косо смотрят.
Ну или если .NET, то вдруг он не стоит? Такое тоже иногда случается =)
Еще общая тормознутость WMI угнетает.

Но строгих "противопоказаний" нет конечно.
В общем так — если "это" можно сделать через реестр или через WMI то лично я бы предпочел через реестр.

bnk>>Можно просто сделать еще один шажок с реестром, и все будет окей
SM>Шажок не так прост, как кажется на первый взгляд. Например, если на 64-битную версию Windows поставить 32-битный SQL Server, то информацию о нём нужно искать в ветке HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SQL Server, а не в той, которая используется в примере.

Ну да. 32 vs 64 — разбираться надо

bnk>>N.B. это работает для SQL 2005/2008, для SQL SERVER 2000/MSDE 2000 и ниже это не сработает
SM>Автор просил для 2008-го, так что это не критично. Но для старых версий, действительно, всё по-другому.

А, понятно

Здравствуйте, bnk, Вы писали:

bnk>Ну например, вдруг WMI вообще выключена? И такое бывает =)
bnk>Далее, WMI, это же типа скрипты (=CreateObject, COM). Некоторые тупые антивирусы на скрипты в инсталляторах косо смотрят.

Понятно, а CreateObject("WScript.Shell") — это типа не скрипты. И не COM. И WSHost отключить нельзя.

bnk>Ну или если .NET, то вдруг он не стоит? Такое тоже иногда случается =)

.NET в данном случае — просто средство для написания примера. Можно и без него.

bnk>Еще общая тормознутость WMI угнетает.

Это да, есть такое.


Моё предложение использовать WMI, а не реестр, было, в основном, из-за того, что я неоднократно встречал мнение, что ключи реестра для SQL Server официально не документированы и его разработчики не обязаны поддерживать их совместимость между разными версиями сервера и ОС. А WMI — это унифицированное средство, которое должно работать с любыми новыми версиями. По крайней мере, так планировалось.

Хотя, я сейчас поискал информацию по используемым свойствам (SKUNAME, SPLEVEL и т.п.) и тоже не нашёл официальной документации. Так что не знаю, кому верить.

Здравствуйте, Sergei MO, Вы писали:

bnk>>Далее, WMI, это же типа скрипты (=CreateObject, COM). Некоторые тупые антивирусы на скрипты в инсталляторах косо смотрят.

SM>Понятно, а CreateObject("WScript.Shell") — это типа не скрипты. И не COM. И WSHost отключить нельзя.

Я же это, не предлагаю вставлять этот скрипт в исталлятор. Он просто для наглядности, чтобы идею продемонстрировать (ключи реестра, которые читать надо)...
Из реестра надо читать или встроенными средствами WI, или же например через CA. Я просто имел в виду, что реестр "отключить" нельзя, а WMI можно.

SM>Моё предложение использовать WMI, а не реестр, было, в основном, из-за того, что я неоднократно встречал мнение, что ключи реестра для SQL Server официально не документированы и его разработчики не обязаны поддерживать их совместимость между разными версиями сервера и ОС. А WMI — это унифицированное средство, которое должно работать с любыми новыми версиями. По крайней мере, так планировалось.
SM>Хотя, я сейчас поискал информацию по используемым свойствам (SKUNAME, SPLEVEL и т.п.) и тоже не нашёл официальной документации. Так что не знаю, кому верить.

Ну не знаю. Я бы проголосовал за реестр