EF（6.1）代碼優先存儲過程問題

因此，我對EF 6.1有一個反向工程（代碼優先）方法。我正在使用POCO生成器VS擴展從現有數據庫生成（逆向工程）我的表等。EF（6.1）代碼優先存儲過程問題

在我的上下文類中，我調用了用於插入，刪除和更新事件的存儲過程，是一個問題：

modelBuilder.Entity<StandardAdditionalInformation>().MapToStoredProcedures(s => 
      s.Insert(u => u.HasName("standard_additionalinformation_save") 
        .Parameter(p => p.Notes, "Notes") 
        .Parameter(p => p.StandardOptout, "StandardOptout") 
        .Parameter(p => p.StandardOptoutReason, "StandardOptoutReason") 
        .Parameter(p => p.IsDeleted, "IsDeleted") 
        .Parameter(p => p.CreateDate, "CreateDate") 
        .Parameter(p => p.CreatedByAccountId, "CreatedByAccountId") 
        .Parameter(p => p.UpdateDate, "UpdateDate") 
        .Parameter(p => p.ModifiedByAccountId, "ModifiedByAccountId") 
      ).Update(u => u.HasName("standard_additionalinformation_save") 
        .Parameter(p => p.StandardId, "StandardId") 
        .Parameter(p => p.ClassId, "ClassId") 
        .Parameter(p => p.Notes, "Notes") 
        .Parameter(p => p.StandardOptout, "StandardOptout") 
        .Parameter(p => p.StandardOptoutReason, "StandardOptoutReason") 
        .Parameter(p => p.IsDeleted, "IsDeleted") 
        .Parameter(p => p.CreateDate, "CreateDate") 
        .Parameter(p => p.CreatedByAccountId, "CreatedByAccountId") 
        .Parameter(p => p.UpdateDate, "UpdateDate") 
        .Parameter(p => p.ModifiedByAccountId, "ModifiedByAccountId") 
      ).Delete(u => u.HasName("standard_additionalinformation_delete") 
        .Parameter(p => p.StandardId, "StandardId") 
        .Parameter(p => p.ClassId, "ClassId") 
     ));

所以，基本上，調用存儲過程很簡單，只要 db.Set（）添加（值）; //其中value是一個StandardAdditionalInformation對象。 db.SaveChanges（）;

對於絕大多數電話（99％）它將是一個更新。

我的問題就在這裏：當我調用更新，我帶有一個例外：

Procedure or function standard_additionalinformation_save has too many arguments specified.

因此，進一步挖掘，運行SQL跟蹤，等以後，我想出了這個作爲實際更新呼叫：

exec [dbo].[gsp_dal_teacherclass_standard_additionalinformation_save] @StandardId=12,@ClassId=1,@Notes=N'blah',@StandardOptout=0,@StandardOptoutReason=N'',@IsDeleted=0,@CreateDate='2014-05-02 13:03:00',@CreatedByAccountId=34068,@UpdateDate='2014-05-12 10:05:04.6067328',@ModifiedByAccountId=34068,@StandardAdditionalInformation_StandardId=NULL,@StandardAdditionalInformation_ClassId=NULL

EF好像是注入2個參數到SPROC呼叫：

@StandardAdditionalInformation_StandardId=NULL 
@StandardAdditionalInformation_ClassId=NULL

這些在ANYWHERE代碼中沒有被引用，但是它們是表格本身PK的值。

有什麼我失蹤了嗎？我的意思是，存儲過程不應該只用上下文構建器中定義的參數來調用？我的工作是將這兩個參數添加到存儲介質中，並且工作得很好，我只是認爲這是一個非常骯髒的解決方案，不希望它得到刺激！

來源

2014-05-12 SlackerCoder

經過深入研究，我發現有問題的桌子上有一個PK和FK是相同的。我刪除了FK，並修改了PK，使其更符合對錶結構進行的一些更改，這些代碼被寫入並繁榮後，它可以正常工作。

我想我提出這個問題的「解決方案」：

不EF生成的代碼，這將迫使參數的存儲過程？ IE瀏覽器。 EF是否意識到PK/FK的存在並知道尋找多對多的關係，因此它會注入它認爲應該存在的參數？

來源

2014-05-12 15:39:15 SlackerCoder

EF（6.1）代碼優先存儲過程問題

回答

相關問題