Split aus: ID bei neuem Datensatz herausfinden
-
Hallo Experten,
ich hänge mich an den Thread, da ich vorbildlich die Suchfunktion benutzt habe und es auch irgendwie passt.
Grundsatzfrage:
Ist es möglich, im "BatchMode" an die einzelnen neuen Identities zu kommen - und ist das für die Praxis überhaupt relevant !?gibt es ein "OleDbConnection"-Beispiel das soll mal der Startpunkt sein.
und darin steht
// Update the database, inserting the new rows.
adapter.Update(dataChanges);jetzt ändere ich es folgend:
// Update the database, inserting the new rows.
Adapter.UpdateBatchSize = 2;
adapter.Update(dataChanges);Ich habe das für SQL-Server umgeschrieben und komme daher auf
https://msdn.microsoft.com/de-de/library/system.data.sqlclient.sqlcommand.updatedrowsource(v=vs.110).aspxerhalte einen Fehler und füge noch ein:
adapter.InsertCommand.UpdatedRowSource = UpdateRowSource.None;Ergebnis: ich lande in "if (e.StatementType == StatementType.Batch)"
der Aufruf erfolgt einmalig und ich erhalte damit die _letzte_ newIDprivate static void OnRowUpdated(object sender, SqlRowUpdatedEventArgs e) { if (e.Status == UpdateStatus.ErrorsOccurred) { e.Row.RowError = e.Errors.Message; e.Status = UpdateStatus.SkipCurrentRow; Console.WriteLine("{0}: {1}", e.Row.RowError, e.Command.CommandText); } else { // Conditionally execute this code block on inserts only. if (e.StatementType == StatementType.Insert) { SqlCommand cmdNewID = new SqlCommand("SELECT @@IDENTITY", e.Command.Connection); //SqlCommand cmdNewID = new SqlCommand("SELECT SCOPE_IDENTITY()", e.Command.Connection); // Retrieve the Autonumber and store it in the CategoryID column. var newID = cmdNewID.ExecuteScalar(); e.Row["CategoryID"] = Convert.ToInt32(newID); e.Status = UpdateStatus.SkipCurrentRow; } if (e.StatementType == StatementType.Batch) { SqlCommand cmdNewID = new SqlCommand("SELECT @@IDENTITY", e.Command.Connection); //SqlCommand cmdNewID = new SqlCommand("SELECT SCOPE_IDENTITY()", e.Command.Connection); // Retrieve the Autonumber and store it in the CategoryID column. var newID = cmdNewID.ExecuteScalar(); e.Row["CategoryID"] = Convert.ToInt32(newID); e.Status = UpdateStatus.SkipCurrentRow; } } }
Die Frage ist eigentlich - irre ich mich oder gibt es nur wenige Einsatzgebiete
in denen so ein Anwendungsfall zutrifft. Das Verhalten ist für mich logisch, aber macht es überhaupt Sinn im BatchMode "neue" Datensätze zu generieren oder
ist es nicht in der Realität immer so, dass die Datensätze bereits eine ID haben - sprich - aus einer anderen Datenquelle stammen und übertragen werden in eine neue - wobei die ID erhalten bleiben sollen.
-
RED-BARON schrieb:
ich hänge mich an den Thread, da ich vorbildlich die Suchfunktion benutzt habe und es auch irgendwie passt.
Bevor du so etwas machst, frage dich ernsthaft, ob es für jemanden, der deine Frage beantworten soll, irgendwie wichtig wäre, zuerst den alten Thread zu lesen (der hier immerhin länger als eine Seite war), bevor sie zu deiner Frage kommen. Das ist hier offensichtlich nicht der Fall, daher habe ich es abtrennen müssen.
-
RED-BARON schrieb:
Das Verhalten ist für mich logisch, aber macht es überhaupt Sinn im BatchMode "neue" Datensätze zu generieren oder ist es nicht in der Realität immer so, dass die Datensätze bereits eine ID haben - sprich - aus einer anderen Datenquelle stammen und übertragen werden in eine neue - wobei die ID erhalten bleiben sollen.
Auch wenn ich jetzt nicht zu der OleDbConnection viel sagen kann (nutze sie meist nur für einmalige Datenimporte), kann ich zu dem Rest vielleicht etwas sagen.
Es gibt durchaus Stellen in einem Projekt, an denen ich viele neue Datensätze in einem Batch erzeuge. Bei den Fällen, in denen das der Fall ist, benötige ich in der Regel aber nicht die einzelnen Ids in dem weiteren Programmablauf, sondern habe eine "Parent-Id". z.B. Viele Veranstaltungen die zu einem Studienjahrgang erzeugt werden. Rechtezuordnungen zu einem Benutzer... Kurz gesagt handelt es sich hier um abhängige Datensätze die in großer Menge zu einem anderen Datensatz erzeugt werden (Wenn ich die Ids wirklich brauchen sollte, könnte ich sie über den übergeordneten Datensatz selektieren).
-
@RED-BARON
Ich kann dir jetzt keinen Fall aus der Praxis sagen wo ich das gemacht oder dringend gebraucht hätte. Grundsätzlich kann es diese Fälle aber sehrwohl geben.Erstmal ist fraglich ob man es überhaupt immer (oder so gut wie immer) einen bestehenden Key gibt. Dann, wenn es so einen Key gibt, ist fraglich ob man ihn übernehmen kann bzw. will. Wenn man z.B. Daten aus mehreren Quellen importiert kann man den Key oft nicht 1:1 übernehmen. Natürlich kann man den Key erweitern indem man ihn um z.B. eine Quellen-ID erweitert. Will man aber nicht unbedingt immer - zumindest nicht als Primary Key. Was dann gleich der nächste Punkt ist: was wenn der Key mehrspaltig ist, vielleicht gar aus ein paar String-Feldern besteht? Sowas will man oft nicht als Primary Key haben. Also muss ein Surrogate Key her. Wobei man da natürlich als Workaround die automatisch generierten Surrogate-Keys wieder aus der Tabelle raus-selecten kann, indem man auf den übernommenen Candidate-Key filtert. Wenn der Candidate-Key mehrspaltig ist, und man es so richtig performant haben will, wird das allerdings auch wieder etwas kompliziert.
Und dann bleiben wie gesagt die Fälle wo man wirklich keinen Candidate-Key hat.
Und brauchen tut man das dann immer da, wo man abhängige Datensätze mit importieren möchte. Also wo man irgendeine Kopftabelle und Detailtabellen hat, und Daten in beide importieren muss. Denn um die Detailtabellen zu befüllen braucht man logischerweise den Key aus der Kopftabelle.