EF CodeFirst: Ofwel de parameter @objname is dubbelzinnig of de geclaimde @objtype (COLUMN) is verkeerd

Ik heb een tabel met de naam EducationTypes en een entiteit met de naam EducationType, ik heb een van de entiteitseigenschappen hernoemd, nu krijg ik vaak Either the parameter @objname is ambiguous or the claimed @objtype (COLUMN) is wrong. Hoe kan ik dit probleem oplossen?

Het gegenereerde SQL-script:

EXECUTE sp_rename @objname = N'dbo.EducationTypes.nvarchar', @newname = N'EducationTypeTitle', @objtype = N'COLUMN'

Antwoord 1, autoriteit 100%

Als u Code First gebruikt en (een) bestaande migratiescript(s) hebt en probeert een wijziging te overschrijven (d.w.z. een kolom hernoemen) die sindsdien is verwijderd, krijgt u die foutmelding. De eenvoudigste manier is om het migratiescript, Add-Migration via NuGet, te verwijderen en vervolgens de database bij te werken.


Antwoord 2, autoriteit 33%

Dit komt door naamconflict van klasse (model)namen met andere gereserveerde of gegenereerde namen, wanneer de tabellen automatisch worden gemaakt en … .

Aangezien EF Code First de interventietabellen maakt om 2 of meer tabellen te relateren met behulp van de naam van tabellen voor de afgeleide interventietabel, dus wanneer u een klassenaam gebruikt die een naam gebruikt zoals de interventietabellen, krijgen we dit dubbelzinnig fout.

Als u bijvoorbeeld een klasse Question heeft met een navigatie-eigenschap Answer, bevatten de interne modelmetadata een verwijzing met de naam QUESTION_ANSWER

Probeer om dit op te lossen de klassenamen (die worden gebruikt voor het genereren van tabellen) te veranderen en zorg ervoor dat ze uniek zijn.


Antwoord 3, autoriteit 9%

Ik kreeg dit met Entity Framework 6 toen ik probeerde een externe sleutel in mijn migratiescript te hernoemen met behulp van de Sql(” … “) methode. De oplossing die ik had was om vierkante haken rond de naam te gebruiken:

d.w.z. dit veranderen:

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

…naar dit:

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

SQL Server kan dan de externe sleutel vinden.


Antwoord 4, autoriteit 6%

Ik heb gewoon veel te veel tijd besteed om erachter te komen waarom dit gebeurde in een productiedatabase waar ik alleen toegang toe heb via mylittlesql. Kon het probleem niet reproduceren, maar heb dit script gemaakt van stukjes sp_rename, dus als het de volgende keer gebeurt, kan ik precies achterhalen waarom. Ja is overdreven, maar kan iemand anders helpen.

Er is een probleem als het u ooit lukt om ‘[‘ of ‘]’ in de eigenlijke kolomnaam te krijgen zoals opgeslagen in sys.columns, (? ‘nvarchar’ als uw kolomnaam ???? ). PARSENAME kan niet omgaan met []’s en retourneert null, dus sp_rename werkt niet.

Dit helpt alleen bij het diagnosticeren van het probleem voor het ‘kolom’-geval met de foutcode 15248, waar ik dit probleem blijf houden:

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

Hierdoor worden enkele nuttige berichten weergegeven op het tabblad Berichten (van SSMS of wat u ook gebruikt) en de tabelvelden op het tabblad Resultaten.

Veel succes.


Antwoord 5, autoriteit 6%

Ik had net hetzelfde probleem, ook na refactoring. Voor mij werd het probleem veroorzaakt door een migratie die ook opnieuw werd uitgevoerd.

Het resultaat was dat een andere migratie niet kon worden uitgevoerd omdat die migratie op zoek was naar een tabel door op de oude naam te zoeken.

Door de wijzigingen in de migratie ongedaan te maken, is dit probleem opgelost.


Antwoord 6, autoriteit 6%

Blijf uit de buurt van gereserveerde woorden of klasnamen in uw migratietitel.

Dit overkwam mij toen ik een migratie “Init” noemde – hernoemd naar “InitialCreate” en alles werkte perfect


Antwoord 7

Eigenlijk treedt deze fout ook op wanneer u zojuist de database hebt verwijderd en uw context niet beseft dat uw database er niet is.

Ik heb de database opnieuw gemaakt en nu is de fout opgelost.

P.S. zorg ervoor dat u controleert of de database er nog is wanneer u de update-database probeert uit te voeren


Antwoord 8

Voor mij gebeurde het toen:

  • Nieuwe migratie toegevoegd (migratoin1)
  • Bijgewerkt in de lokale database
  • Vervolgens dezelfde migratie verwijderd (migratoin1)
  • Vervolgens met dezelfde naam (migratoin1) nog een migratie toegevoegd
  • Vervolgens toegepast op de lokale database en gepubliceerd.

Het verwijderen van het migratiebestand (migratoin1) loste mijn probleem op.


Antwoord 9

dit is mij overkomen omdat automatische migraties waren ingesteld op true en een van de programmeurs die nieuw is, heeft migraties aan het project toegevoegd, dus bij het bijwerken van de database zou het in de war raken.
loste het op door de bestaande migratie uit het project te verwijderen en weer te rekenen op automatische updates.


Antwoord 10

Ik heb deze fout opgelost door alle oude migraties te verwijderen uit de Migratiegeschiedenistabel van Mijn database in de SQL-server en vervolgens een nieuwe toe te voegen, maar alleen voor de gewenste wijzigingen en vervolgens de database te updaten. Het werkte prima.

LEAVE A REPLY

Please enter your comment!
Please enter your name here

17 + seven =

Other episodes