SQL Server Mgmt Studio для SQL Server 2008 R2 говорит, что .Net 2.0?

Использование SQL Server Mgmt Studio с SQL Server 2008 R2. Возникли проблемы с запуском известный хороший SQL-запрос из php-кода (просто не будет работать, никаких ошибок не сообщается). После проверки, единственное, что нашел не так было SSMS > Help > Aboutговорит:

Microsoft SQL Server Management Studio        10.50.6000.34
Microsoft Data Access Components (MDAC)       3.85.1132
Microsoft MSXML                               2.6 3.0 4.0 5.0 6.0 
Microsoft Internet Explorer                   8.0.6001.18702
Microsoft .NET Framework                      2.0.50727.3655
Operating System                              5.1.2600

Сообщенное значение .Net Framework слишком низкое. На этой машине установлены .Net 2.0, 3.5-sp1, 4.0. В веб-статьях, которые я читал, говорилось, что для запуска диспетчера сервера выберите вкладку функции, включите .Net 3.5 sp1. Но Win XP, похоже, не имеет менеджера услуг, Adminpak.msi для XP не имел его, и Windows Power Shell 32bit и не удалось импортировать модуль Service Manager.

Пожалуйста, посоветуйте.

1 ответ

  1. В течение нескольких недель после того, как этот вопрос был первоначально опубликован, некоторые
    появилось дополнительное понимание.

    В комментариях сказано:

    «Это версия встроенной среды CLR SQL-.NET
    Платформа, встроенная в ядро SQL Server. SQL Server 2005 через
    2008 R2 используется .NET 2.0,…».

    Таким образом, для моей установки SQL Server Express 2008 R2 следующее
    считается правильным:

    SSMS > справка > > о программе>>
    Microsoft .NET Framework 2.0.50727.3655

    Еще одним новым пониманием является то, что (вопреки комментариям) существует способ повлиять (включить/отключить) на указанные установленные версии .Net Framework (в Windows XP SP3).

    Рассмотрим следующий файл:
    C:\Documents и настройки\локальные настройки\данные приложения\
    Microsoft_Corporation\LandingPage.exe_StrongName_ryspccglaxmt4nhllj5z3
    thycltsvyyx\
    10.0.0.0\пользователь.конфиг

    (где строка 3) говорит:
    Система.Конфигурация.UserSettingsGroup, System, Version=4.0.0.0

    (где строка 4) говорит:
    Система.Конфигурация.ClientSettingsSection, System, Version=4.0.0.0

    Эти записи версии были написаны установщиком mssql и сильно подозреваются (хотя и не доказано), чтобы ссылаться на (самый высокий) установленный пакет .Net Framework (на этой машине).
    Чтобы поддержать это заявление, пожалуйста, рассмотрите следующую ссылку URL.

    https://social.msdn.microsoft.com/Forums/sqlserver/en-US/d4d657bd-8212-4287-b5ed-e6055cbceb09/config-error-refers-to-version-4000-after-retargeting-to-2000-even-after-changing-all?forum=netfxbcl

    (Этот пользователь не испытал никаких проблем, описанных в этом URL, но привел его в качестве ссылки только для поддержки предполагаемой связи между версией в user.конфигурация и установленная версия .Net Framework.)

    Для этого пользователя требовалось несколько попыток установки mssql-сервера. При более ранней попытке установщик mssql написал версию 2.0… в пользователя.конфигурационный файл (который был быстро отброшен). При более поздней попытке установщик mssql написал версию 4.0… в пользователя.конфигурационный файл (на той же машине, которая была принята). Обратите внимание, что версия, написанная установщиком, не была одинаковой в обоих экземплярах установки и трудно объяснить. (Этот пользователь в конечном итоге пошел с версией 4.0….)

    Вторым дополнительным пониманием является наличие (существование) пользователя.файл конфигурации (в этом точном расположении пути) из более ранней установки mssql заставляет установку MS sql server express 2008 R2 останавливаться дважды по ошибке (в начале и в конце) и запрашивать разрешение пользователя на продолжение. Продолжение производства приемлемой установки. Но большинство комментаторов, кажется, рекомендуют удалить этого пользователя.config-файл remnant от предыдущей установки перед новой установкой и просто позвольте установщику mssql воссоздать его. (Хотя любой пользователь.файл конфигурации, ссылающийся менее чем на v4.0… не был принят этим пользователем.)

    Кстати, после тщательного исследования корневая проблема, которая вызвала этот вопрос (в первую очередь), оказалась не связанной с версией .Net Framework (вообще) и вместо этого была прямым результатом искаженной строки запроса.