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

Ответ 1

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

USE SomeDatabase

Ответ 2

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

TRUNCATE TableName

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

DELETE FROM TableName

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

Ответ 3

Выполняет ли пользователь этот script даже видеть эту таблицу?

select top 1 * from products

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

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

Ответ 4

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

Ответ 5

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

Шаги по устранению этой проблемы

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

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

вы можете обратиться к "Разделение прав собственности и разделов пользователей в SQL Server"

Ответ 6

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

Или до script это будет:

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

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

Ответ 7

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

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

Проблема была на самом деле с ПРОТИВОПОКАЗАНИЯМИ. Я переименовал таблицу на DEV в old_XXX несколько месяцев назад. Но когда я попытался скопировать оригинал из PROD, имена Defaut Constraint столкнулись.

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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

Ответ 10

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

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