【问题标题】:EF code first foreign key ignored, getting "Invalid column name"EF 代码第一个外键被忽略,得到“无效的列名”
【发布时间】:2015-03-30 05:48:15
【问题描述】:

我有一个相当简单的类,它包含潜在的用户类型:

public class Core_UserType
{
    [Key]
    public long ID { get; set; }
    [Required]
    public String Name { get; set; }    
    [ForeignKey("TrackingInfo")]
    public long ObjectID { get; set; }

    public virtual Core_TrackingInfo TrackingInfo { get; set; }
}

为简洁起见,我排除了一些代码,但关键属性是TrackingInfo。这个实体(以及整个代码优先实体模型都在一个名为 EntityModel 的类库中。

该解决方案有 2 个 Web 应用程序项目(都是 ASP.Net MVC),它们都引用了这个类库。

在库本身中有一些代码插入了一些条目,其中一个是新的Core_UserType。当从应用程序 A 调用时,它会完美运行。问题是当从项目 B 调用时,代码失败(在插入一些其他对象之后):

保存不公开外键的实体时出错 他们关系的属性。 EntityEntries 属性将 返回 null,因为无法将单个实体标识为源 的例外。可以进行保存时的异常处理 通过在实体类型中公开外键属性更容易。看 InnerException 了解详情。

还有一个内部异常:

无效的列名 TrackingInfo_ID

我深入挖掘了堆栈跟踪,发现项目 B 正在尝试执行此 SQL:

INSERT [dbo].[Core_UserType]([Name], [ObjectID], [TrackingInfo_ID])
VALUES (@0, @1, @2)
SELECT [ID]
FROM [dbo].[Core_UserType]
WHERE @@ROWCOUNT > 0 AND [ID] = scope_identity()

显然TrackingInfo_ID 不存在(它应该使用ObjectID)所以它失败了。

问题是为什么项目 A 能够兑现 ForeignKey 属性而项目 B 不能?

【问题讨论】:

  • 您能否展示您对 Core_TrackingInfo 的定义?我怀疑您正在尝试创建 1:1 或 1:0..1 关系,而您不能这样做。
  • 是的,它像 1:1 一样使用,但定义为 1:many。 Core_TrackingInfo 方面有这个:public virtual ICollection<Core_UserType> Core_UserTypes { get; set; }。至关重要的是,尽管项目 A 中这一切都很好,所以我认为模型本身没有任何问题。

标签: c# .net asp.net-mvc entity-framework ef-code-first


【解决方案1】:

您可以尝试以相反的方式执行此操作:这意味着另一个属性上的 ForeignKey DataAnotaion:

public long ObjectID { get; set; }

[ForeignKey("ObjectID")]
public virtual Core_TrackingInfo TrackingInfo { get; set; }

希望这会有所帮助!

【讨论】:

  • 不正确。您可以通过任何一种方式指定它。见msdn.microsoft.com/en-us/library/…The annotation may be placed on the foreign key property and specify the associated navigation property name, or placed on a navigation property and specify the associated foreign key name
  • @ErikFunkenbusch 感谢您的明确。但我怀疑,这将有助于解决 OP 的问题,因为显然它已将 TrackingInfo 解释为它自己的 ForeignKey 并使用自动生成的 TrackingInfo_ID
  • 我怀疑这会有什么不同,因为我怀疑他可能试图建立一种 1 对 1 的关系,而这种方式无法做到。
  • 我不敢相信这有效!我和@ErikFunkenbusch 一样持怀疑态度,认为这不会有任何区别,但它完全有效。谢谢!
  • @BenC3 - 嗯..我的猜测是,它可能是通过将其移动到另一个属性而重新生成的。我敢打赌,如果你把它移回去,它仍然可以工作。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2016-01-24
  • 2014-02-14
  • 2015-07-29
  • 2022-09-28
  • 1970-01-01
相关资源
最近更新 更多