Строка соединения ADO по сети

[Mirra88]

Не знаю правильно ли я выбрала рубрику для своей темы, но просмотрев форум увидела близкие моей темы именно в этой рубрике. В общем я пытаюсь подключиться к таблицам базы данных SQL server 2005 Express при помощи Builder2006-приложения с удалённого компьютера. Мне уже пояснили, что лучше всего тут использовать средства ADO. Состроила UDL-файл:
 "Provider=SQLOLEDB.1;Password=1;Persist Security Info=True;User ID=sa;Initial Catalog=tat;data Source=TAT2\SQLEXPRESS"
 И нигде не могу ни найти, ни вставить ничего похожего на сеть, на сетевой путь! Это я привела UDL-файл локального ПК. Удалённый же, когда я пытаюсь с удалённого подсоединиться к этому локальному, на котором вот так вот прописана база, выдаёт:
 "[Microsoft][Диспетчер драйверов ODBC] Источник данных не найден и не указан драйвер используемый по умолчанию"
 В принципе я могла бы на удалённом ПК написать UDL-файл подключения по-другому. Но кто-нибудь может посоветовать источники, где бы пояснялось как можно составить ADO-строку подключения В СЕТИ?

[RXL]

Посмотри это: http://www.connectionstrings.com/

[Dimka]

Mirra88, сетевой путь здесь: TAT2 - сетевое имя машины (в смысле сети Windows). Его можно заменить на сетевое имя (в смысле DNS, например "localhost") или IP-адрес (например "127.0.0.1").

Затем немаловажным моментом является доступность протоколов для SQLServer.

Для этого на машине, где стоит сервер, нужно запустить SQL Server Configuration Manager (в меню Пуск найти можно). Затем посмотреть по дереву Network Configuration/Protocols for <экземпляр>. Где <экземпляр> в твоём случае - это SQLEXPRESS. По умолчанию из всех протоколов включен только Shared Memory, т.е. сервер работает лишь на локальной машине. Для доступа по сети нужно включить: для локальной сети Windows - Named Pipes, в более общем случае - TCP/IP.

На машине клиента нужно запустить либо тот же SQL Server Configuration Manager и выбрать Native Client Configuration/Client Protocols (но это будет доступно, только если на машине установлен локальный SQLServer), либо программу cliconfg (эта утилита входит в ADO и присутствует в любой Windows - от 2000 и выше; запустить в консоли или через Пуск/Выполнить). И в открывшемся окне добиться, чтобы был включен хотя бы один из протоколов, которые включены на сервере.

[Mirra88]

Спасибо за содержательные советы! Что касается ссылки, то тут я ещё не успела разобраться, там всё на английском, поэтому у меня это быстро не получится.. А вот что касается настройки сервера и клиента, то тут я уже всё сделала. На сервере включила все протоколы менеджером, а на клиенте через cliconfg. Причём cliconfg SQL-сервер, находящийся на удалённом ПК, увидела! Я зашла на вкладочку "псевдоним", а там уже само, без всякого моего вмешательсво указано: "\\192.168.1.5\SQLEXPRESS", т. е. IP-адрес и наименование удалённого сервера, я просто даже глазам своим не поверила! Но хотя ПК-клиент удалённый SQL-сервер явно видит, Builder через компонент ADOconnection подключаться к нему не хочет. Мало того, что когда я (через драйвер Microsoft OLE DB provider for SQL server) пытаюсь строку подключения создать, то список SQL-серверов в форме пустой, так ещё когда я ввожу то же название (\\192.168.1.5\SQLEXPRESS) вручную, он, при попытке найти БД в выпадающем списке, выдаёт "[DBNETLIB] Connection open(Connect()).]Указанный SQL-сервер не найден" И через IP-адрес и через имя удалённого ПК. Если же я ввожу имя нужной БД (tat) вручную, то пишет "Не выполнена проверка подключения из-за ошибки инициализации поставщика."[DBNETLIB] Connection open(Connect()).]Указанный SQL-сервер не найден". Не могу понять, почему если удалённый SQL-сервер увидел ПК-клиент, его всё равно не видит Builder установленный на этом же ПК-клиенте. Может быть Builder-у не хватает каких-то библиотек или пакетов.. Оба ПК я уже перезагружала, не помогает..

[Dimka]

Я зашла на вкладочку "псевдоним", а там уже само, без всякого моего вмешательсво указано: "\\192.168.1.5\SQLEXPRESS", т. е. IP-адрес и наименование удалённого сервера, я просто даже глазам своим не поверила!

Вот с этого места поподробнее. Я ни в какую мистику не верю.

Если задан псевдоним (alias), то именно его надо указывать на этой клиентской машине в качестве сервера. Т.е. если написано, что A=192.168.0.1\SQLEXPRESS, то в строке соединения Data Source=A, а не чему-то другому.

[Mirra88]

Я бы могла: "Вот с этого места поподробнее" если бы сама что-то тут понимала.  Но вот к нахождению источника неудачи я всё-таки стала ближе! После того, как я попробовала создать просто ODBC-подключение (без Builder), то стало ясно, что дело вовсе не в Builder, оказывается не удаётся создать удалённое подключение к этому SQL-серверу вообще (хотя я уже отключила брандмауэры и антивирусники, компы видят и пингуют друг друга). Что ж проблему можно решить только поняв её причину!
Сейчас я займусь вопросами сетевого взаимодействия компов и приложений, но это уже другие темы форума.. А после решения сетевых вопросов вернусь к этой теме, и я думаю, что тогда и она решится!

[Dimka]

Ну я сразу могу сказать, что по TCP сервер должен (по умолчанию, если никто ничего не менял) открывать на прослушивание порт 1433. Соответственно, в выдаче утилиты netstat этот порт должен присутствовать как открытый на прослушивание на нужном сетевом интерфейсе, а при помощи telnet с ним должно быть возможно установить соединение.

Если нужно более подробное пояснения про netstat и telnet - могу дать.

[Mirra88]

Спасибо. В ответ на команду "telner 192.168.1.5 1433" ПК-клиент выдавал мне, что ему не удалось открыть подключение к этому узлу на этот порт. А "netstat -a" ни на сервере, ни на клиенте порт 1433 в выведенном списке открытых портов почему-то не показывает. Хотя на сервере (локально)открывается и работает с базой программа, база которой как раз на этом SQL-сервере. И через диспетчер конфигурации SQL-сервер я повключала все и сетевые и клиентские порты. А в свойствах включенного TCP/IP-порта программы cliconfg (хоть клиента, хоть сервера) высвечивается именно 1433.

[Dimka]

Mirra88, значит TCP/IP не включен. А локально с сервером программы работают через, например, shared memory. Порт должен быть открыт на прослушивание на сервере (не на клиенте).

Проделал у себя всю процедуру включения - как ни странно, пришлось повозиться. Даже если протокол на сервере включен, порт 1433 для 2005-го сервера по умолчанию не устанавливается, а используется так называемый Dynamic Port. Чтобы включить порт, в свойствах протокола надо перейти на вторую вкладку и в самом низу списка задать порт для всех (ну или свой порт для каждого сетевого интерфейса).

Добавлено через 13 часов, 57 минут и 9 секунд:
Mirra88, кстати, при смене настроек протоколов сервера, надеюсь, ты обращала внимание на выскакивающее окошко, гласящее о том, что изменения не вступят в силу до перезапуска службы SQLServer.

[Mirra88]

  УРА, УРА всё вопрос решён, я подключилась! Спасибо тем, кто мне помогал, благодаря вам я прожила эту неделю не зря. Спасибо Dimka за то, не пожалел времени повозиться и проделать у себя всю процедуру включения - благодаря  подсказке о второй страничке свойств tcp/ip протокола я только и смогла в конце-концов подключиться, а когда я дошла бы до этого сама одному Богу известно. Вначале подключился ODBC, а потом, когда "мост" был налажен, то, как я и предполагала, без труда подключился и Builder. Я несколько вещей сразу сделала: включила IP и назначила им стат порты 1433 на второй странице tcp/ip-свойств SQL сервера, поменяла там же IP-адрес на адрес своего сервера, назначила конкретный порт 1433 в cliconfg. Что из этого стало решающим - не знаю. Главное что всё получилось (но порт 1433 netstat -a, как ни странно,  в выведенном списке открытых портов всё-равно почему-то не показывает). Спасибо! Теперь, когда удалось установить связь, можно учиться запускать Builder-ом хранимые на SQL-сервере процедуры и делать множество других интересных вещей!

[Dimka]

но порт 1433 netstat -a, как ни странно,  в выведенном списке открытых портов всё-равно почему-то не показывает

Смотря где смотреть. На клиенте его и не должно быть. Он должен быть на сервере. Если его нет на сервере, тогда ты подключилась при помощи другого протокола - может решающей оказалась перезагрузка сервера.

[Mirra88]

Либо я подключилась с помощью другого протокола, либо этот "маскируется" под какой-нибудь ms-sql-s (надо будет поэкспериментировать), потому что после перезагрузки 1433 тоже нет, но зато есть несколько вот таких "безномерных"протоколов, а ведь, я так подозреваю, у них тоже есть номер, просто программа netstat их выводит по именам по каким-то причинам, напрмер, по причине того, что их может быть несколько разных, или по каким-то иным причинам.

[Dimka]

Mirra88, добавь ключик -n и посмотри номера, если хочешь.

[Mirra88]

Dimka, да с ключем -n порт 1433 в списке открытых портов появляется, но.. Наконец-то я поняла смысл фразы найденной на другом форуме: "порт может быть активен, только если его открыла (и держит открытым) какая-то программа". Этот порт появляется в списке открытых портов только тогда, когда я держу открытым УСТАНОВЛЕННОЕ соединение при помощи своей Builder-программки. как-только я эту программку закрываю (не меняя больше ничего ни на сервере ни на клиенте!), так этот порт из списка исчезает. Значит даже если бы SQL-сервер был бы у меня правильно настроен, а соединение не устанавливалось бы по каким-то иным причинам (например, из-за неправильной настройки клиента), то этого порта в списке бы не было ДАЖЕ ПРИ ПРАВИЛЬНО НАСТРОЕННОМ SQL-СЕРВЕРЕ. Тоесть делать вывод о правильности сетевых настроек SQL-сервера по признаку отсутствия этого порта в списке открытых - не верно.

[Dimka]

Mirra88, нет, такое утверждение справедливо для клиента, но не для сервера. На сервере порт открыт всегда, пока запущена сама служба сервера. Этот порт открыт на прослушивание (состояние LISTENING) и находится в колонке локальных адресов. Для клиента порт открыт лишь на период подключения (состояние ESTABLISHED или другие) и находится в колонке внешних адресов.

Возможно, в твоём случае всё же как-то задействован динамический порт - его номер непредсказуемо меняется, но текущий показывается в настройках протокола TCP/IP на сервере.