Laden...

[erledigt] Ef to Sql

Erstellt von Diräkt vor 10 Jahren Letzter Beitrag vor 10 Jahren 1.134 Views
D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 10 Jahren
[erledigt] Ef to Sql

verwendetes Datenbanksystem: SQL + EF (DB-First)

Hallo Leute 😃

Ziel:
=> Diverse "Template" Scripts welche heute als SQL Scripts existieren sollen gecoded werden in c#.
( Damit Spaltennamens-Änderungen etc. durch compilerfehler schneller gefunden werden usw...)

Problem:
Die Tabellen haben ein PK (auto increment) für diese Templates (werden geladen beim Aufsetzen der Software), muss dieses Feature ausgeschalten werden.

Sowas hier:

 using (var myDB = new newDB())
            {
                //turn off the identity column 
                myDB.ExecuteStoreCommand("SET IDENTITY_INSERT [MyDataTable] OFF");
               
                 //insert template data

               // turn on the identity column
               myDB.ExecuteStoreCommand("SET IDENTITY_INSERT [MyDataTable] ON");
            }

funktioniert leider nur nicht. (oder nur bedingt). Man müsste im EF Model einiges anpassen (StoreGeneratedPattern) ... was bei jedem Model Update wieder überschrieben werden würde (also keine Lösung)

Idee:

Nun kam ich auf folgende Idee:

 using (var myDB = new newDB())
            {
                db.DummyData.Add(new DummyData(){Id=1,Name="HalloWelt"});
                db.DummyData.Add(new DummyData(){Id=1,Name="HalloWelt"});
            }

Anstatt das ich nun db.SaveChanges() aufrufen würde, möchte ich sowas haben:
db.GenerateSaveChangesSqlScript().

Kennt jemand eine solche Möglichkeit oder hat eine Lösung für das Problem?

Beste Grüsse

Diräkt

D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 10 Jahren

Nachtrag:

=> Per Reflection hab ich es hingekriegt das SQL Statement rauszuholen das SaveChanges() absetzen würde.***

Leider bleibt das grundsätzliche Problem bestehen:

=> StoreGeneratedPattern=identity

Es scheint sobald dies gesetzt ist (edmx...), kann man da nicht wirklich viel machen nachträglich 😦.
2 Models zu haben ist für mich auch keine Lösung.

***
"=============== BEGIN COMMAND =\r\n\r\ninsert [dbo].[Role]([Name], [HtmlRemarks], [LastModified], [LastModifiedUserId])\r\nvalues (@0, null, @1, @2)\r\nselect [RoleId]\r\nfrom [dbo].[Role]\r\nwhere @@ROWCOUNT > 0 and [RoleId] = scope_identity()\r\n@0 = test\r\n@1 = 13.05.2013 06:00:03\r\n@2 = 0\r\n\r\n= END COMMAND ===============\r\n"

Jemand noch eine Idee ?

Beste Grüsse

Diräkt

Edit:

Was klappen würde ist:
db.Database.ExecuteSqlCommand("DBCC CHECKIDENT('Role',RESEED,1000);");

Aber das ist echt etwas gammlig... 😦

C
282 Beiträge seit 2008
vor 10 Jahren

DU könntest es andersherum machen. Das Model nicht aus der Datenbank generieren, sondern die Datenbank aus dem Model generieren. Wenn ich es richtig verstanden habe, wolltest du ja ohnehin die Datenbank aus dem Code updaten.

Grundsätzlich sehe ich selten einen Sinn vom EF irgendwas zu SQL zu extrahieren. Dann macht es doch mehr Sinn gleich mit SqlConnection und SqlCommand zu arbeiten.

D
Diräkt Themenstarter:in
615 Beiträge seit 2009
vor 10 Jahren

Hallo Cannon

Danke für Deine Antwort.

Das Model nicht aus der Datenbank generieren, sondern die Datenbank aus dem Model generieren.

Wir haben den Ansatz DB-First gewählt, daher ist dies keine Option.

Es geht "lediglich" darum keine SQL Scripts mehr zu haben um "Template" (Initial) Daten zu laden. Bei Spalten-Namen Änderung (als Beispiel) haben wir somit keine Compiler Prüfung etc. Daher sollen die Datensätze via EntityObjects in die DB gespeichert werden.

Wir lösen es nun mit Reseed:

db.Database.ExecuteSqlCommand("DBCC CHECKIDENT('Role',RESEED,1000);");

Ist meiner Meinung nach nicht ganz schön, somit können wir aber die ID's festlegen für die Initial (template) Daten.

Beste Grüsse

Diräkt