Odbc sql server driver sql server не удалось найти хранимую процедуру

Обновлено: 23.01.2025

Собственно не могу подключиться к MSSQL серверу по ODBC через 1с
Может кто знает куда копать ? как починить.

Попробую по пунктам описать куда копать:
1. стандартный порт для подключение по ODBC 1433 проверяем висит ли что то на этом порту:
netstat -an | find"1433"
2. Если да то копаем в сторону фаервола. разрешаем правила - либо целиком отключаем:
Если у вас включен Windows Firewall (или любой другой), необходимо открыть порт 1433
Если нетстат показывает что ничего не висит на 1433 то проверяем по пунктам:
1. Запускаем SQL Server Configuration Manager
В окне конфигурации SQL Server выберите ветку Network Configuration SQL Server -> Протоколы для SQL Server. Затем включите необходимые порты. Обычно достаточно TCP/IP.
- также в этом окошке откройти закладку ip adresses - и там в самом низу порт - он может быть не стандартный. (подключаться надо на него)

После этого перейдите в ветку Настройка собственного клиента SQL Клиентские протоколы. Произведите настройку необходимых протоколов. Обычно достаточно TCP/IP с настройками по умолчанию. Если вы измените номер порта, его нужно будет разблокировать в файрволе, а также указывать при соединении с SQL сервером. Рекомендуется оставить номер порта по умолчанию – 1433

2. После конфигурации протоколов, перейдите в ветку «Службы SQL Server». Перезапустите SQL Server.
3. Запустите Microsoft SQL Server Management Studio (среду управления сервером баз данных) и подключитесь к серверу. Кликните правой кнопкой мышки по серверу. В появившемся меню выберите «Свойства».
- В разделе «Безопасность» поставьте «Проверка подлинности SQL Server и Windows».
- В разделе «Соединения» установите опцию «Разрешить удаленные соединения с этим сервером».

ПЕРЕЗАПУСТИТЕ СЛУЖБУ SQL SERVERA.
ВОЗМОЖНО КОМУ ТО ПОМОЖЕТ: Фактический порт TCP для подключения через ODBC можно найти в реестре по адресу HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\<Instance Name>\MSSQLServer\SuperSocketNetLib\Tcp

Услуги Системного Администратора - Работаю только с Юр. Лицами по договору обслуживания.

И еще раз я об этом написал с самого начала, с чего стоит копать, стандартный порт подключения 1433
т.е мы на самом сервере должны понять.

1. Запустите NETSTAT -A чтобы просмотреть список открытых портов (скажем, LISTENING). Если 1433 нет среди них, то SQL-сервер не работает или не прослушивает этот порт.

2. Если в списке указано 1433, проверьте локальный брандмауэр, чтобы узнать, разрешает ли он подключение к/из локального хоста и/или разрешает подключения к 1433.

3. Вы можете попробовать TELNET 1433 (к локал хост и к внешнему ip с другово клиент)

Услуги Системного Администратора - Работаю только с Юр. Лицами по договору обслуживания.

Что делать если вы не видите открытый стандартный порт 1433, способы понять, какой порт использует ваш MSSQL

1. через (SQL Server Configuration Manager) - описал в самом первом посте и в посте ниже - этого.
2. через логи событий
3. SQL Server Error Logs
4. через выполнение SQL запроса.
5. через реестр - описал в первом ответе

---- описание всех способов:

By default SQL Server listens on TCP port number 1433, and for named instances TCP port is dynamically configured. There are several options available to get the listening port for SQL Server Instance.

Here are a few methods which we can use to get this information.

Method 1: SQL Server Configuration Manager

Method 2: Windows Event Viewer

Method 3: SQL Server Error Logs

Method 4: sys.dm_exec_connections DMV

Method 5: Reading registry using xp_instance_regread

Let's see how you can use each of these methods in detail:

Method 1: SQL Server Configuration Manager:

Step 1. Click Start > All Programs > Microsoft SQL Server 2012 > Configuration Tools > SQL Server Configuration Manager

Step 2. Go to SQL Server Configuration Manager > SQL Server Network Configuration > Protocols for <Instance Name>

Step 3. Right Click on TCP/IP and select Properties

Step 4. In TCP/IP Properties dialog box, go to IP Addresses tab and scroll down to IPAll group.

If SQL Server if configured to run on a static port it will be available in TCP Port textbox, and if it is configured on dynamic port then current port will be available in TCP Dynamic Ports textbox. Here my instance is listening on port number 61499.

Method 2: Windows Event Viewer:

When SQL Server is started it logs an event message as 'Server is listening on [ 'any' <ipv4> <port number>' in windows event logs. Here <port number> will be actual port number on which SQL Server is listening.

To view this using Event Viewer:

Step 1. Click Start > Administrative Tools > Event Viewer.

Note: If Administrative Tools are not available on Start menu, go to Start > Control Panel > System and Maintenance > Administrative Tools > View event logs

Step 2. Navigate to Event Viewer > Windows Logs > Application

Step 3. Since huge amount of event are logged, you need to use filtering to locate the required logs. Right click on Application and select Filter Current Log…

Step 4. You can filter the events by Event ID and Event source. The event we are interested in has Event ID of 26022, and it’s source is SQL Server Instance. You need to filter by both Event ID and SQL Server Instance if you have multiple instances installed, for a single instance you can filter by Event ID only. Click on OK to apply the filter.

Step 5. Once the filter is applied, Locate message 'Server is listening on [ 'any' <ipv4> …'. As we can see from below screenshot that SQL Server Instance is running on TCP Port 61499.

Method 3: SQL Server Error Logs:

When SQL Server is started it also logs an message to SQL Server Error Logs. You can search for port number in SQL Server Error Logs by opening SQL Server Error Log in notepad or via T-SQL using extended stored procedure xp_ReadErrorLog as below:

EXEC xp_ReadErrorLog 0, 1, N'Server is listening on', N'any', NULL, NULL, 'DESC'

LogDate ProcessInfo Text

2013-03-21 13:34:40.610 spid18s Server is listening on [ ‘any’ <ipv4> 61499].

2013-03-21 13:34:40.610 spid18s Server is listening on [ ‘any’ <ipv6> 61499].

(2 row(s) affected)

As we can see from the output that SQL Server Instance is listening on 61499.

Note: This method does not work if SQL Server Error Logs have been cycled. See sp_Cycle_ErrorLog for more information.

Method 4: sys.dm_exec_connections DMV:

DMVs return server state that can be used to monitor SQL Server Instance. We can use sys.dm_exec_connections DMV to identify the port number SQL Server Instance is listening on using below T-SQL code:

WHERE session_id = @@SPID

(1 row(s) affected)

As we can see from the output… same as above Smile

Method 5: Reading registry using xp_instance_regread:

Port number can also be retrieved from Windows Registry database.

We can use extended stored procedure xp_instance_regread to get port number information using below T-SQL code:

DECLARE @portNumber NVARCHAR(10)

'Software\Microsoft\Microsoft SQL Server\MSSQLServer\SuperSocketNetLib\Tcp\IpAll',

@value = @portNumber OUTPUT

SELECT [Port Number] = @portNumber

(1 row(s) affected)

As we can see … same as above Smile Smile

Note: The above code will only work if SQL Server is configured to use dynamic port number. If SQL Server is configured on a static port, we need to use @value_name = 'TcpPort' as opposed to @value_name = 'TcpDynamicPorts'.

Hope This Helps!

Услуги Системного Администратора - Работаю только с Юр. Лицами по договору обслуживания.

Статические и динамические порты SQL Server

Microsoft SQL Server может работать в двух режимах:
Прослушивание одного порта (по-умолчанию это TCP порт 1433). Этот режим будет выбран по-умолчанию, если во время установки SQL Server не использовать именованный экземпляр.
Динамический выбор портов. В этом случае при запуске SQL Server выберет свободный порт. Этот режим будет выбран по-умолчанию, если во время установки SQL Server настроить на использование именованного экземпляра.

Для того чтобы определить и изменить режим работы SQL Server нужно:
Открыть "Диспетчер конфигурации SQL Server"
В левом столбце выбрать "Сетевая конфигурация SQL Server" -> "Протоколы для <инстанция SQL Server>"
В правом столбце дважды кликнуть по протоколу TCP/IP
В открывшемся окне в разделе IPAll указано два параметра:
"TCP порт" - при помощи этого параметра можно задать статический порт. По-умолчанию значение 1433.
"Динамические TCP порты" - при помощи этого параметра можно задать диапазон, из которых будет выбираться порт для SQL Server

Я поддерживаю классический веб-сайт ASP, который имеет бэкэнд SQL Server 2005. Для небольшой части новой функциональности я написал хранимую процедуру для вставки. Это единственная пользовательская хранимая процедура в базе данных.

когда я пытаюсь вызвать хранимую процедуру из кода, я получаю следующую ошибку:

БД использует проверку подлинности SQL Server. Когда я подключаюсь к серверу БД в Visual Studio, используя тот же пользователь/pw, что и в строке подключения, хранимая процедура не отображается, но отображаются все таблицы.

пользователь имеет роли datareader и datawriter и явное разрешение на выполнение хранимой процедуры.

UPDATE: мои извинения, администратор сервера неправильно информировал меня, что это был сервер 2000, когда на самом деле это сервер 2005 (работает на Windows Server 2003 x64).

возможно, Вам потребуется проверить, кто является фактическим владельцем хранимой процедуры. Если это конкретный другой пользователь, то именно поэтому вы не можете получить к нему доступ.

иногда это также может произойти, когда у вас есть хранимая процедура вызывается с параметрами. Например, если вы наберете что-то вроде:

Это будет работать однако,:

это вызовет ошибку " не удалось найти хранимую процедуру dbo.StoredProcedure "продукты", однако это можно легко преодолеть с помощью parantheses вот так:

убедитесь, что имя вашей схемы находится в строке подключения?

1-имя процедуры хранения При объявлении процедуры хранения в коде убедитесь, что не exec или execute ключевое слово например:

MSDBHelp.ExecuteNonQuery(sqlconexec, CommandType.StoredProcedure, sqlexec);

CommandType.StoreProcedure будет искать только имя процедуры хранения и ExecuteNonQuery выполнит процедуру хранения за сценой.

2 - строка подключения:

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

использовать [wrong_place]

не удалось найти хранимую процедуру?---- когда получишь это.. наш код такой

у меня есть 4 DBs (sample1, sample2, sample3), но stmt будет искать место master по умолчанию DB, то мы получим исключение.

мы должны предоставить имя БД, затем проблема решается::

еще одна возможность проверить. Листинг здесь, потому что это просто случилось со мной и не упомянули;-)

Я случайно добавил пробел в конце имени. Много часов попыток, прежде чем я, наконец, заметил это. Это всегда что-то простое после того, как ты это выяснишь.

Я создал таблицу testtable внутри базы данных testbase , которая имеет следующую структуру:

, который я использовал Microsoft Management Studio для Microsoft SQL Server 2008.

Я создал хранимую процедуру testtable_pricesmaller следующим образом

и могут просматривать хранимые процедуры в Object Explorer Microsoft SQL Server Management Studio. (Он указан в следующей древовидной структуре Object Explorer )

Мне очень странно, когда я получаю следующую ошибку:

, когда я выполняю следующий оператор SQL:

Что это может быть пропало?

Студия управления MS SQL Server требует перезапуска после создания в ней хранимой процедуры.

После перезапуска MS SQL Server Management Studio такой ошибки больше нет.

(Странно, значит ли это, что каждый раз, когда я создаю хранимую процедуру, я должен ее перезапустить?)

Вам не нужно перезапускать базу данных после добавления новой хранимой процедуры, хотя вам нужно будет обновить объект-проводник, чтобы увидеть его там.

В следующий раз, когда вы добавите хранимую процедуру, попробуйте запустить опцию правой кнопки мыши из объекта explorer и ввести свои параметры и посмотреть, выполняется ли она. Если он не запускается, я не уверен, в чем проблема. Если он запускается, это может быть что-то простое, как SQL пытается выполнить запрос из неправильной базы данных.

Ваша команда create должна быть

вам не хватает dbo. перед именем процедуры. Всякий раз, когда вы создаете процедуру, хорошей практикой является явное определение пользователя /схемы с именем процедуры, то есть имя процедуры должно иметь полностью квалифицированные подписи.

Надеюсь, это поможет вам.

Я знаю, что это старо. Я столкнулся с этим вопросом, когда искал решение этой же проблемы, и я отправляю этот ответ в надежде, что он поможет другим, которые также найдут этот вопрос.

Чтобы решить эту проблему, я изменил базу данных по умолчанию для входа в экземпляр SQL Server из мастера в базу данных, содержащую хранимую процедуру, которую хотел выполнить отчет.

При работе с SSMS помните, что панель Object Explorer - это одно соединение, в то время как любой редактор имеет совершенно другое соединение. Таким образом, вы можете увидеть объекты для SQL01 в Обозревателе объектов, но код, который вы используете в редакторе, будет работать против SQL02 - я сталкивался с этой проблемой несколько раз за эти годы и после долгих раздумий и «Почему не будет это работает? " осознал мою ошибку. Для редактора посмотрите в нижнем правом углу, чтобы узнать, к какому экземпляру и базе данных вы подключены.

TL; DR: У вас может быть хранимая процедура, вызывающая другую хранимую процедуру, которая не существует.

У меня была эта проблема и я нашел исправление. Вот что произошло. Я создал одну хранимую процедуру:

Затем я создал другую хранимую процедуру, которая выполнила первый

Мое решение состояло в том, чтобы изменить мою вторую хранимую процедуру, чтобы использовать новое имя:

Вот простой способ проверить, есть ли у вас эта проблема. Нажмите, чтобы изменить текст хранимой процедуры и затем выполнить этот текст. Если вы получите такое предупреждение, вам нужно переименовать хранимую процедуру:

У меня есть (многие) хранимые процедуры, которые на самом деле являются синонимами. Хранимая процедура существует канонически в одной базе данных, но видна в других.

Хранимая процедура выполняется отлично изнутри SQL Server Management Studio:

И если я подключаюсь к SQL Server с помощью любого поставщика OLEDB:

Затем хранимая процедура выполняет штраф. Я получаю результаты. И все счастливы.

Но не с драйвером ODBC

С объявлением об отказе от драйверов OleDb, я хотел протестировать с помощью драйверов ODBC для SQL Server. Когда я меняю соединение на использование одного из драйверов ODBC SQL Server (например, "" ) и выполняю ту же инструкцию SQL

Запрос процедуры "Report_ThirdParty" завершился неудачно, потому что "Report_ThirdParty" является объектом синонима

Это верно, если я использую оригинальный драйвер ODBC для SQL Server или собственный клиент:

В обоих вариантах я получаю ту же ошибку:

[Microsoft] [Собственный клиент SQL Server 11.0] [SQL Server] Запрос процедуры "Report_ThirdParty" завершился неудачно, поскольку "Report_ThirdParty" является объектом синонима

или для более старого драйвера ODBC:

[Microsoft] [драйвер SQL Server ODBC] [SQL Server] Запрос процедуры "Report_ThirdParty" не удался, потому что "Report_ThirdParty" является объектом синонима

Запрос процедуры "% s" не выполнен, потому что "% s" - это объект синонима

Errors коллекция Connection предоставляет дополнительную информацию:

Нет никакого вреда в отказе от переключения на ODBC. И я не собираюсь прекращать использовать синонимы.

Но что не так, и как я могу сказать, что драйвер ODBC для SQL Server работает?

Читайте также: