EF CodeFirst: либо параметр @objname является неоднозначным, либо заявленный @objtype (COLUMN) неверен
У меня есть стол с именем EducationTypes и сущность по имени EducationTypeЯ переименовал одно из свойств объекта, теперь я часто получаю Either the parameter @objname is ambiguous or the claimed @objtype (COLUMN) is wrong, Как я могу решить эту проблему?
Сгенерированный скрипт SQL:
EXECUTE sp_rename @objname = N'dbo.EducationTypes.nvarchar', @newname = N'EducationTypeTitle', @objtype = N'COLUMN'
12 ответов
Если вы используете Code First и имеете (есть) существующие сценарии миграции и пытаетесь перезаписать изменение (т.е. переименование столбца), которое с тех пор было удалено, то вы получите эту ошибку. Самый простой способ - удалить скрипт миграции Add-Migration через NuGet, а затем обновить базу данных.
Это происходит из-за конфликта имен классов (моделей) с другими зарезервированными или сгенерированными, когда auto создает таблицы и... .
Учитывая, что EF Code First создает промежуточные таблицы, чтобы связать 2 или более таблиц, используя имена таблиц для производной промежуточной таблицы, поэтому при использовании имени класса, использующего имя, подобное промежуточным таблицам, мы получим такую неоднозначную ошибку.
Например, если у вас есть класс Question, у которого есть свойство навигации Answer, внутренние метаданные модели будут содержать ссылку с именем QUESTION_ANSWER.
Чтобы решить эту проблему, попробуйте изменить имена классов (используемые для генерации таблиц) и обеспечить их уникальность.
Я получил это с Entity Framework 6 при попытке переименовать внешний ключ в моем скрипте миграции, используя метод Sql(" ... "). Обходной путь, который у меня был, заключался в использовании квадратных скобок вокруг имени:
т.е. меняя это:
sp_rename 'FK_dbo.tablename_dbo.othertablename_fieldname', 'FK_dbo.tablename_dbo.othertablenewname_fieldnewname', 'object'
...к этому:
sp_rename '[FK_dbo.tablename_dbo.othertablename_fieldname]', 'FK_dbo.tablename_dbo.othertablenewname_fieldnewname', 'object'
SQL Server может найти внешний ключ.
Держитесь подальше от зарезервированных слов или имен классов в заголовке миграции.
Это случилось со мной, когда я назвал миграцию "Init" - переименовал в "InitialCreate", и все работало отлично
Просто потратил слишком много времени, пытаясь выяснить, почему это происходит в производственной базе данных, доступ к которой я могу получить только через mylittlesql. Не смог воспроизвести проблему, но сделал этот скрипт из битов sp_rename, поэтому, когда это произойдет в следующий раз, я смогу точно выяснить, почему. Да, это излишне, но может помочь кому-то еще.
Существует проблема, если вам когда-нибудь удастся вставить '[' или ']' в фактическое имя столбца, которое хранится в sys.columns (? 'Nvarchar' в качестве имени вашего столбца????). PARSENAME не справляется с [] и возвращает ноль, поэтому sp_rename не будет работать.
Это только поможет диагностировать проблему для случая "столбца" с кодом ошибки 15248, где я продолжаю иметь эту проблему:
declare @objname nvarchar(1035) = N'dbo.EducationTypes.nvarchar' -- input to sp_rename
declare @newname sysname = N'EducationTypeTitle' -- input to sp_rename
declare @UnqualOldName sysname,
@QualName1 sysname,
@QualName2 sysname,
@QualName3 sysname,
@OwnAndObjName nvarchar(517),
@SchemaAndTypeName nvarchar(517),
@objid int,
@xtype nchar(2),
@colid int,
@retcode int
select @UnqualOldName = parsename(@objname, 1),
@QualName1 = parsename(@objname, 2),
@QualName2 = parsename(@objname, 3),
@QualName3 = parsename(@objname, 4)
print 'Old Object Name = ''' + convert(varchar,isnull(@UnqualOldName ,'')) + ''''
-- checks that parsename is getting the right name out of your @objname parameter
print 'Table name:'
if @QualName2 is not null
begin
print QuoteName(@QualName2) +'.'+ QuoteName(@QualName1)
select @objid = object_id(QuoteName(@QualName2) +'.'+ QuoteName(@QualName1))
end
else
begin
print QuoteName(@QualName1)
select @objid = object_id(QuoteName(@QualName1))
end
-- check if table is found ok
print 'Table Object ID = ''' + convert(varchar,isnull(@objid ,-1)) + ''''
select @xtype = type from sys.objects where object_id = @objid
print '@xtype = ''' + convert(varchar,isnull(@xtype,'')) + ''' (U or V?)'
if (@xtype in ('U','V'))
begin
print 'select @colid = column_id from sys.columns where object_id = ' +
convert(varchar,isnull(@objid,0)) + ' and name = ''' +
@UnqualOldName + ''''
select * from sys.columns where object_id = @objid -- and name = @UnqualOldName
select @colid = column_id from sys.columns
where object_id = @objid and name = @UnqualOldName
print 'Column ID = ''' + convert(varchar,isnull(@colid,-1)) + ''''
end
Это выведет некоторые полезные сообщения на вкладку "Сообщения" (SSMS или чего-либо еще) и поля таблицы на вкладке "Результаты".
Удачи.
У меня просто была такая же проблема, также после рефакторинга. Для меня проблема была вызвана миграцией, которая также подверглась рефакторингу.
В результате другая миграция не может быть выполнена, так как эта миграция искала таблицу, ища ее старое имя.
Возврат изменений в миграции решил эту проблему.
У меня только что была эта ошибка, и я решил это, изменив частичный класс миграции, миграция попыталась переименовать индекс, а индекс не существовал, я просто меняю код миграции следующим образом:
- Удалить переименование в методе индекса
- Установите индекс создания в пустоте Up
- Установите индекс падения в пустоте Down
это решило мою проблему.
На самом деле эта ошибка также происходит, когда вы просто удалили базу данных, и ваш контекст не понимает, что вашей базы данных там нет.
Я воссоздал базу данных, и теперь ошибка была устранена.
PS убедитесь, что вы проверяете базу данных все еще там, когда вы пытаетесь запустить update-database
Я получил эту ошибку, когда сначала обновлял свою базу данных, используя код. Я создал таблицу с внешним ключом, и кто-то другой переименовал этот внешний ключ. Теперь, когда я попытался обновить базу данных, это исключение.
Я выполнил следующие шаги, чтобы решить эту проблему:
- Пришлось удалить эту таблицу из моей базы данных
- Отслеживается, какая миграция добавила эту таблицу и удалила ее из истории миграций на сервере SQL.
- В конце концов, снова запустили update-database, и моя база данных успешно обновилась.
Со мной это случилось, когда:
- Добавлена новая миграция (migratoin1)
- Обновлено в локальной базе данных
- Затем удалил ту же миграцию (migratoin1)
- Затем добавили с тем же именем (migratoin1) еще одну миграцию
- Затем применяется к локальной базе данных и публикуется.
Удаление файла миграции (migratoin1) решило мою проблему.
Я решил эту ошибку, удалив все старые миграции из моей таблицы истории миграции базы данных на сервере SQL, а затем добавив новую, но только для желаемых изменений, а затем обновил базу данных. Все работало нормально.
Это случилось со мной, потому что автоматические миграции были установлены на true, и один из новых программистов добавил миграции в проект, поэтому при обновлении базы данных он запутался. решил это, удалив существующую миграцию из проекта и снова рассчитывая на автоматические обновления.