Не удается найти объект, поскольку он не существует или у вас нет прав. Ошибка в SQL Server

Question

У меня есть база данных и сценарий Sql для добавления некоторых полей в таблицу под названием «Продукты» в базе данных.

Но когда я выполняю этот скрипт, я получаю следующую ошибку:

Cannot find the object "Products" because it does not exist or you do not have permissions

Почему происходит ошибка и что мне нужно сделать, чтобы ее устранить?

Answer 1

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

TRUNCATE TableName

Поскольку TRUNCATE удаляет элементы без регистрации, вам (очевидно) необходимы повышенные разрешения для выполнения хранимой процедуры, которая ее содержит. Мы изменили заявление на:

УДАЛИТЬ ИЗ TableName

... и ошибка ушла!

Answer 2

Вы уверены, что выполняете сценарий для правильной базы данных? В SQL Server Management studio вы можете изменить базу данных, к которой вы выполняете запрос, в раскрывающемся списке на одной из панелей инструментов, или вы можете запустить свой запрос с помощью этого:

USE SomeDatabase

Answer 3

Видит ли пользователь, для которого вы выполняете этот скрипт, даже эту таблицу?

select top 1 * from products

Получаете ли вы какой-либо вывод для этого ??

Если да: имеет ли этот пользователь право изменять таблицу, т.е. выполнять сценарии DDL, такие как ALTER TABLE и т. Д.? Обычно обычные пользователи не имеют таких повышенных разрешений.

Answer 4

Это также может произойти из-за опечатки в ссылке на таблицу, например [dbo.Product] вместо [dbo].[Product].

Answer 5

Также возможно, что вы создали «Продукты» в своей схеме входа в систему и пытались выполнить то же самое в другой схеме (возможно, dbo)

Действия по решению этой проблемы

1) открыть студию управления 2) Найдите объект в проводнике и определите схему, под которой находится ваш объект? (это текст перед именем вашего объекта). На изображении ниже его "dbo", и мое имя объекта - состояние действия

если вы видите это как "yourcompanydoamin \ yourloginid", тогда вам следует Вы можете изменить разрешение для этой конкретной схемы, а не для любой другой схемы.

Вы можете сослаться на «Владение и разделение схемы пользователя в SQL Server»

Answer 6

Вы можете щелкнуть правой кнопкой мыши по процедуре, выбрать свойства и посмотреть, какие разрешения предоставлены вашему логину. Затем вы можете вручную отметить «Выполнить» и изменить разрешение для процедуры.

Или написать это так:

GRANT EXECUTE ON OBJECT::dbo.[PROCNAME]
    TO [ServerInstance\user];

GRANT ALTER ON OBJECT::dbo.[PROCNAME]
    TO [ServerInstance\user];

Answer 7

Я пытался скопировать таблицу из PROD в DEV, но получил ошибку: «Не удается найти объект X, потому что он не существует или у вас нет прав.»

Однако таблица действительно существовала, и я работал как sa, поэтому у меня были разрешения.

Проблема была на самом деле с ОГРАНИЧЕНИЯМИ. Я переименовал таблицу на DEV в old_XXX несколько месяцев назад. Но когда я попытался скопировать оригинал из PROD, имена ограничений Defaut столкнулись.

Сообщение об ошибке вводило в заблуждение

Answer 8

Это может быть проблема разрешения. Пользователю необходимо как минимум разрешение ALTER для усечения таблицы. Другим вариантом является вызов DELETE FROM вместо TRUNCATE TABLE, но эта операция медленнее, потому что она записывает в файл журнала, тогда как TRUNCATE не записывает в файл журнала.

Требуемое минимальное разрешение - ALTER для table_name. TRUNCATE TABLE разрешения по умолчанию для владельца таблицы, члены sysadmin исправлены роль сервера и фиксированные роли базы данных db_owner и db_ddladmin, и не подлежат передаче. Тем не менее, вы можете включить TRUNCATE Оператор TABLE внутри модуля, такой как хранимая процедура, и грант соответствующие разрешения для модуля с использованием предложения EXECUTE AS.

Answer 9

Делюсь своим делом, надеюсь, это поможет.

В моей ситуации внутри MY_PROJ.Database->MY_PROJ.Database.sqlproj Я должен был поставить это:

<Build Include="dbo\Tables\MyTableGeneratingScript.sql" />

Answer 10

В моем случае я работал под другим пользователем, чем тот, которого я ожидал.

У меня была 'DRIVER={SQL Server};SERVER=...;DATABASE=...;Trusted_Connection=false;User Id=XXX;Password=YYY' в качестве строки подключения, которую я передал pypyodbc.connect(), но соединение все еще использовало учетные данные пользователя Windows, который запустил сценарий (я проверил это с помощью SQL Server Profiler и попытавшись ввести неверный uid комбинация пароль / пароль - что не привело к ожидаемой ошибке).

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

conn = pypyodbc.connect(driver='{SQL Server}', server='servername', database='dbname', uid='userName', pwd='Password')