У меня есть база данных и сценарий Sql для добавления некоторых полей в таблицу под названием "Продукты" в базе данных.
Но когда я выполняю этот скрипт, я получаю следующую ошибку:
Cannot find the object "Products" because it does not exist or you do not have permissions
Почему происходит ошибка и что я должен сделать для ее устранения?
Вы уверены, что выполняете script по отношению к правильной базе данных? В студии SQL Server Management вы можете изменить базу данных, в которой выполняется запрос, в раскрывающемся списке на одной из панелей инструментов, или вы можете начать свой запрос с помощью этого:
USE SomeDatabase
Я нашел причину, почему это произойдет. У пользователя были соответствующие разрешения, но хранимая процедура включала инструкцию TRUNCATE:
TRUNCATE TableName
Поскольку TRUNCATE удаляет элементы без регистрации, вам (очевидно) необходимы повышенные разрешения для выполнения хранимой процедуры, которая ее содержит. Мы изменили выражение на:
DELETE FROM TableName
... и ошибка ушла!
Выполняет ли пользователь этот script даже видеть эту таблицу?
select top 1 * from products
Получаете ли вы какой-либо результат для этого?
Если да: имеет ли этот пользователь разрешение на изменение таблицы, то есть выполнение сценариев DDL, таких как ALTER TABLE и т.д.? Обычно обычные пользователи не имеют таких повышенных разрешений.
Это также может произойти из-за опечатки в ссылке на таблицу, например [dbo.Product] вместо [dbo].[Product].
Возможно также, что вы создали "Продукты" в своей схеме входа, и вы пытались выполнить их в другой схеме (возможно, dbo)
Шаги по устранению этой проблемы
1) откройте студию управления 2) Найдите объект в проводнике и определите схему, под которой находится ваш объект? (это текст перед именем вашего объекта). На изображении ниже его "dbo" и мое имя объекта - это статус действия
если вы видите это как "yourcompanydoamin\yourloginid", тогда вы должны вы можете изменить разрешение на эту конкретную схему, а не любую другую схему.
вы можете обратиться к "Разделение прав собственности и разделов пользователей в SQL Server"
Вы можете щелкнуть правой кнопкой мыши по процедуре, выбрать свойства и посмотреть, какие разрешения предоставляются вашему идентификатору входа. Затем вы можете вручную проверить "Выполнить" и изменить разрешение для proc.
Или до script это будет:
GRANT EXECUTE ON OBJECT::dbo.[PROCNAME]
TO [ServerInstance\user];
GRANT ALTER ON OBJECT::dbo.[PROCNAME]
TO [ServerInstance\user];
Я пытаюсь скопировать таблицу из PROD в DEV, но получить ошибку: "Не удается найти объект X, потому что он не существует или у вас нет разрешений".
Однако таблица действительно существует, и я работал как sa, поэтому у меня были разрешения.
Проблема была на самом деле с ПРОТИВОПОКАЗАНИЯМИ. Я переименовал таблицу на DEV в old_XXX несколько месяцев назад. Но когда я попытался скопировать оригинал из PROD, имена Defaut Constraint столкнулись.
Сообщение об ошибке вводит в заблуждение
В моем случае я работал под другим пользователем, чем тот, которого я ожидал.
У меня была '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')
Делюсь своим делом, надеюсь, это поможет.
В моей ситуации внутри MY_PROJ.Database->MY_PROJ.Database.sqlproj мне пришлось поместить это:
<Build Include="dbo\Tables\MyTableGeneratingScript.sql" />
Это может привести к разрешению проблемы. Пользователю необходимо как минимум разрешение ALTER для усечения таблицы. Другим вариантом является вызов DELETE FROM вместо TRUNCATE TABLE, но эта операция медленнее, потому что она записывает в файл журнала, тогда как TRUNCATE не записывает в файл журнала.
Минимальное требуемое разрешение - ALTER для table_name. Разрешения TRUNCATE TABLE по умолчанию принадлежат владельцу таблицы, членам предопределенной роли сервера sysadmin, а также предопределенным ролям базы данных db_owner и db_ddladmin и не подлежат передаче. Однако вы можете включить оператор TRUNCATE TABLE в модуль, такой как хранимая процедура, и предоставить соответствующие разрешения модулю с помощью предложения EXECUTE AS.