Я сталкивался с этим, потому что у меня были проблемы с созданием удаленного соединения, и я не мог понять, почему настройка порта 1433 в брандмауэре не работает. Теперь у меня наконец полная картина, поэтому я решил поделиться.
Прежде всего необходимо включить «TCP / IP» с помощью диспетчера конфигурации SQL Server в разделе «Протоколы для SQLEXPRESS!»
Когда используется именованный экземпляр (в данном случае «SQLExpress»), он будет прослушивать динамический порт. Чтобы найти этот динамический порт, у вас есть несколько вариантов; назвать несколько:
проверка ERRORLOG
SQL Server, расположенного в '{MS SQL Server Path}\{MS SQL Server instance name}\MSSQL\Log'
(внутри вы найдете строку, подобную этой: "2013-07-25 10:30:36.83 Server Server is listening on [ 'any' <ipv4> 51118]"
-> поэтому 51118 является динамическим портом в этом случае.
проверка реестра: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\{MSSQL instance name}\MSSQLServer\SuperSocketNetLib\Tcp\IPAll
, для моего случая TcpDynamicPorts=51118
.
Редактировать : {MSSQL instance name}
это что-то вроде: MSSQL10_50.SQLEXPRESS
, не только SQLEXPRESS
Конечно, разрешение этого порта TCP в брандмауэре и создание удаленного соединения путем передачи: "x.x.x.x,51118"
(где x.x.x.x - ip сервера) уже решает его на этом этапе.
Но затем я хотел подключиться удаленно, передав имя экземпляра (например: x.x.x.x\SQLExpress
). Это когда служба SQL Browser вступает в игру. Это устройство, которое разрешает имя экземпляра в порт 51118. Служба браузера SQL прослушивает порт UDP 1434 (стандартный и статический), поэтому мне пришлось разрешить это и в брандмауэре сервера.
Чтобы немного расширить реальный ответ: если кто-то еще не любит динамические порты и хочет статический порт для своего экземпляра SQL Server, попробуйте эту ссылку .