До сих пор я узнал следующие факты о Microsoft SQL Server Express, включая версию 2012, и более ранние версии, такие как 2008R2 и 2008, и, по большей части, вплоть до SQL Server 2005. Я настраиваю SQL SERVER на " «сервер рабочей группы», то есть это выделенный сервер, работающий под управлением ОС Windows Server, но он использует РАБОЧУЮ ГРУППУ, и на нем работает только Microsoft SQL Express.
Обратите внимание на следующие основные факты:
Настройка экземпляра SQL Express происходит из коробки без настройки TCP / IP.
Включение параметра TCP / IP (изменение элемента списка протоколов конфигуратора SQL Server для TCP / IP с Нет на Да) недостаточно, иногда вам также нужно выбрать либо перенастроить параметры статических и динамических портов. Например, для одного экземпляра вы можете установить статический порт на 1433, а динамический порт на пустой (удалив 0, если он есть). Это делается неоднократно, и на некоторых машинах с Windows, имеющих IPV4 и IPV6, а также один физический и несколько виртуальных адаптеров Ethernet, это может быть 4, 8 или даже 16 мест, где вы должны установить статический и динамический порт.
В качестве альтернативы вы можете настроить браузер SQL и включить его, и это часто помогает решить сложные проблемы с подключением TCP / IP, но часто этого не происходит.
В домене я редко есть странные проблемы, поэтому этот вопрос не для развертываний SQL-сервера на основе домена, а скорее для развертываний в рабочих группах. Нет, я не выбирал запуск моего офиса в рабочей группе, но многие из моих клиентов / клиентов ДЕЙСТВИТЕЛЬНО выбирают этот вариант, и я должен поддерживать SQL Express в рабочих группах.
Все вышеперечисленное является предысторией и дано, чтобы прояснить следующую часть, которая является моим фактическим вопросом:
Многие клиентские системы WORKGROUP в сети небольшого офиса, в которой нет домена, похоже, имеют странные проблемы с подключением через TCP / IP или даже с автоматическим согласованием соединения с базой данных SQL Server, которые я не могу воспроизвести ни в одном из моих собственных офисов или домашние сети, в которых соединения SQL не будут работать, даже если запущен браузер SQL и настроены параметры статического и динамического порта SQL, брандмауэры отключены, а ping работает нормально, но подключение TCP / IP с использованием клиента SQL который поставляется внутри компонентов Windows 7 MDAC, НЕВОЗМОЖНО. Обратите внимание, что это не так просто, как установка SQL Native Client v10 или SQL native Client V11. Единственный обходной путь для этих клиентов - отключить TCP / IP с помощью CLICONFG.EXE, а также отключить автосогласование в строке подключения к базе данных SQL, добавив к имени сервера префикс «NP:». Что-то в локальной сети рабочей группы этого клиента принципиально несовместимо даже со статическим одиночным экземпляром SQL Server, прослушивающим TCP-порт 1433, и без браузера SQL или динамического порта.
У этих же клиентов часто есть 12 машин, и 6 из 12 машин НЕ могут подключаться через автоматические (без принудительного использования именованных каналов) строки подключения и могут подключаться только тогда, когда тип подключения принудительно привязан к именованным каналам.
Типичная строка подключения, которая заставляет именованные каналы, может либо поставить «NP:» перед хостом и экземпляром, например: «NP: HOSTNAME \ SQLEXPRESS», плюс мы перейдем к CLICONFG.EXE этого клиента и отключим TCP / IP. Оба шага необходимы в некоторых ситуациях в рабочей группе.
И снова вопрос в том, ПОЧЕМУ половина клиентских систем Windows 7 (в среднем 6 из 12) на некоторых сайтах моих клиентов не имеет возможности выполнять SQL-обмен через TCP / IP по локальным сетям своих рабочих групп.
Некоторые квалификации и общие факты:
Многие из систем, которые не могут подключиться, представляют собой 32-разрядные клиенты Windows 7, в которых не установлены дополнительные компоненты подключения клиента SQL, кроме тех функций MDAC, которые встроены в Windows.
Приложения, с которыми я пытаюсь подключиться, используют ADO и отлично работают с базовыми компонентами MDAC, которые поставляются в Windows 7.
Установка компонента «собственного клиента» для конкретного сервера SQL 2012 или 2008R2 (SQL Native Client 11, SQL Native Client 10) НЕ влияет на эти проблемы, не устраняет их и не делает что-либо лучше или хуже.
Я подозреваю, что существуют некоторые основные проблемы, связанные с IPV4, IPV6, DNS и отсутствием «проблем с доверием», которые затем приводят к тому, что основные части подключения TCP / IP + DNS «частично нарушаются», но я не нашел какой-либо точной документации SQL Server по этому вопросу. .
На этих сайтах клиентов НЕТ домена Windows Active Directory и служб DHCP на базе Windows, и они обычно получают свои динамические IP-адреса через DHCP-сервер, встроенный в низкоуровневую коммерческую или бытовую сеть WiFi + DSL + Router + NAT, такую как Linksys WRT64G. Я даю конкретную модель, чтобы мне было ясно, что у этих пользователей НИЧЕГО нет, что вы могли бы распознать как локальную сеть в "ИТ-стиле". Эти люди управляют небольшими компаниями, у них нет ИТ-бюджета, ИТ-персонала и нет инфраструктуры Windows Network или домена. У них есть один экземпляр SQL Server, работающий на компьютере под управлением Windows Server, приобретенный у поставщика программного обеспечения (я), для запуска программного приложения, и они не хотят переключаться на использование домена.
Все вышесказанное является правдой, и я озадачен, почему SQL через TCP с включенными IPV6 и IPV4 (стандартная 32-разрядная сетевая конфигурация Windows 7) было бы так сложно заставить работать. Единственный частичный ответ, который у меня есть до сих пор, заключается в том, что в НЕКОТОРЫХ случаях, похоже, различия в имени рабочей группы могут быть причиной некоторых проблем. (Машина A не имеет проблем и работает под управлением Windows 7, для нее задано имя рабочей группы WORKGROUP, на компьютере B есть проблемы, она работает в Windows 7 и имеет имя рабочей группы MYCOMPANY.)
Обратите внимание, что связанная с этим сбивающая с толку проблема, на которой могут застрять некоторые люди, связана с выбором между аутентификацией SQL и (интегрированной) аутентификацией Windows. Мы всегда используем аутентификацию SQL при настройке соединений в рабочей группе, и это кажется совершенно необходимым из-за отсутствия домена, и я не об этом спрашиваю. Я спрашиваю ТОЛЬКО о TCP / IP по сравнению с именованными каналами и о причине, по которой я не могу настроить TCP / IP-соединения, которые работают в рабочей группе, и все же я ЖЕСТЯНАЯ БАНКА легко настроить их в большинстве WAN, VPN и даже в Интернете.
Почему ЛВС WINDOWS WORKGROUP - это особый случай подключения TCP / IP к SQL Server Express?
Я подозреваю, что существуют некоторые основные проблемы, связанные с IPV4, IPV6, DNS и отсутствием «проблем с доверием», которые затем приводят к тому, что основные части подключения TCP / IP + DNS «частично нарушаются», но я не нашел какой-либо точной документации SQL Server по этому вопросу. .
Между DNS и TCP нет никакого «доверия», о котором вы говорите. Между DNS и TCP существует взаимосвязь в отношении DNS, облегчающего подключение на основе имен к хостам TCP, но определенно нет никакого «доверия». Чтобы один хост мог подключиться к другому хосту по имени, это имя должно быть разрешаемым. Это называется разрешением имен. Очень часто это достигается с помощью DNS, но в сценарии рабочей группы, который вы описываете, нет центрального DNS-сервера, который бы обрабатывал разрешение имен для клиентов.
В описанном вами сценарии, где не существует общего DNS-сервера для разрешения имен, клиенты будут прибегать к LLMNR или широковещательной рассылке, в зависимости от клиента. Ни один из методов не гарантирует, что каждый хост сможет разрешить имя любого другого хоста.
Это не волшебство и не загадка. Если вы хотите регулярно и надежно преобразовывать имена хостов в IP-адреса, вам необходимо реализовать внутренний DNS-сервер и соответствующим образом настроить клиентов. Для клиентов рабочей группы это означает необходимость вручную настраивать свой DNS-суффикс для соответствия зоне DNS на DNS-сервере, который вы создаете для рабочей группы, а затем настраивать все клиенты для использования этого DNS-сервера для DNS.