EF CodeFirst: Entweder ist der Parameter @objname mehrdeutig oder der behauptete @objtype (COLUMN) ist falsch

Wenn Sie Code First verwenden und über vorhandene Migrationsskripts verfügen und eine Änderung löschen (d. H. Eine Spalte umbenennen) möchten, die inzwischen gelöscht wurde, wird diese Fehlerausgabe angezeigt. Am einfachsten ist es, das Migrationsskript Add-Migration über NuGet zu löschen und anschließend die Datenbank zu aktualisieren.

Dies liegt an name Konflikt der Klassennamen mit anderen reservierten oder generierten, wenn die Tabellen automatisch erstellt werden und.

In Anbetracht dessen, dass EF Code First die Interventionstabellen erstellt, um zwei oder mehr Tabellen mit dem Tabellennamen für abgeleitete Interventionstabellen zu verknüpfen. Wenn Sie also einen Klassennamen verwenden, der einen Namen wie die Interventionstabellen verwendet, wird dieser mehrdeutige Fehler angezeigt.

Wenn Sie beispielsweise eine Question-Klasse mit einer Answer -Navigationseigenschaft haben, enthalten die internen Modellmetadaten eine Referenz mit dem Namen QUESTION_ANSWER

Um dieses Problem zu lösen, versuchen Sie, die Klassennamen (zur Generierung von Tabellen) zu ändern, und stellen Sie sicher, dass sie eindeutig sind.

Ich habe dies mit Entity Framework 6 erhalten, als ich versuchte, einen Fremdschlüssel in meinem Migrationsskript mit der SQL-Methode ("...") umzubenennen. Die Problemumgehung bestand darin, den Namen in eckige Klammern zu setzen:

das heißt, dies ändern:

sp_rename 'FK_dbo.tablename_dbo.othertablename_fieldname', 'FK_dbo.tablename_dbo.othertablenewname_fieldnewname', 'object'

... dazu:

sp_rename '[FK_dbo.tablename_dbo.othertablename_fieldname]', 'FK_dbo.tablename_dbo.othertablenewname_fieldnewname', 'object'

SQL Server kann dann den Fremdschlüssel finden.

Ich habe einfach zu viel Zeit damit verbracht herauszufinden, warum dies in einer Produktionsdatenbank geschieht, auf die ich nur über mylittlesql zugreifen kann. Das Problem konnte nicht reproduziert werden, aber dieses Skript wurde aus sp_rename-Bits erstellt. Wenn es das nächste Mal passiert, kann ich genau herausfinden, warum. Ja ist übertrieben, könnte aber jemand anderem helfen.

Es gibt ein Problem, wenn Sie es jemals schaffen, "[" oder "]" in den tatsächlichen Spaltennamen zu übernehmen, wie er in sys.columns gespeichert ist (("nvarchar" als Spaltenname ????). PARSENAME kann mit [] nicht umgehen und gibt null zurück, daher funktioniert sp_rename nicht.

Dies hilft nur bei der Diagnose des Problems für den 'Spalte'-Fall mit dem Fehlercode 15248, bei dem ich dieses Problem immer wieder habe:

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

Dadurch werden einige hilfreiche Meldungen auf der Registerkarte Nachrichten (von SSMS oder was auch immer Sie verwenden) und den Tabellenfeldern auf der Registerkarte Ergebnisse ausgegeben. 

Viel Glück.

Ich hatte gerade das gleiche Problem, auch nach dem Refactoring. Für mich war das Problem auf eine Migration zurückzuführen, die ebenfalls überarbeitet wurde.

Das Ergebnis war, dass eine andere Migration nicht ausgeführt werden konnte, da bei der Migration eine Tabelle gesucht wurde, indem der alte Name durchsucht wurde.

Durch das Wiederherstellen der Änderungen in der Migration wurde dieses Problem behoben.

Mir ist es passiert, wenn:

• Neue Migration hinzugefügt (migratoin1)
• Aktualisiert in der lokalen Datenbank
• Dann löschte die gleiche Migration (migratoin1)
• Dann fügte man mit dem gleichen Namen (migratoin1) eine weitere Migration hinzu
• Dann auf die lokale Datenbank angewendet und veröffentlicht.

Das Löschen der Migrationsdatei (migratoin1) hat mein Problem gelöst.

Tatsächlich tritt dieser Fehler auch auf, wenn Sie die Datenbank gerade gelöscht haben und Ihr Kontext nicht erkennt, dass Ihre Datenbank nicht vorhanden ist.

Ich habe die Datenbank neu erstellt und der Fehler wurde behoben.

P.S. Stellen Sie sicher, dass die Datenbank noch vorhanden ist, wenn Sie versuchen, die Update-Datenbank auszuführen

Vermeiden Sie reservierte Wörter oder Klassennamen in Ihrem Migrationstitel.

Dies geschah bei mir, als ich eine Migration "Init" nannte - umbenannt in "InitialCreate" und alles funktionierte einwandfrei