Primärschlüssel aus Datenbank ermitteln

[Frank H]

Hallo,

ich habe einmal folgenden Versuch gemacht:

Ich habe ein SELECT-Statement definiert und mit dem Command-Builder einen Update-Befehl generiert, in dem nur die hinzugefügten Datensätze in die Datenbank zurückgeschrieben werden.

Wenn ich danach aus der Datenbank den aktuellsten Wert, der in eine IDENTITY-Spalte oder DEFAULT AUTOINCREMENT-Spalte eingefügt wurde, ermittle, so erhalte ich als Ergebnis immer "0", obwohl ein neuer Datensatz angelegt wurde.

Wenn ich den genau gleichen Befehl dann aber "von Hand" mit einem INSERT-Statement programmiere, liefert die Datenbank danach den korrekten Wert des Primärschlüssels des neu hinzugefügten Datensatzes zurück.

Woran könnte dies liegen?

Gruß
Frank

[Jürgen Thomas]

Das Thema hatten wir doch gerade unter Command-Builder und Primärschlüsselvergabe durch SQL-Server mit den Erklärungen durch Andreas Kosch. Jürgen

[Frank H]

Hallo,

diesen Beitrag habe ich mir genau durchgelesen. Der Vorschlag

Teil B (muss der Entwickler separat konfigurieren)

Code:

SELECT usrtbl_id, wert, datum, benutzer, ts
FROM UsrTbl
WHERE (wert = @wert, datum=@datum, benutzer=@benutzer);

funktioniert aber doch nur, wenn ich sicher weiß, dass mindestens eine dieser Spalten immer unterschiedlich ist und ist damit doch nicht allgemeingültig.
Deswegen habe ich versucht, die IDENTITY-Funktion der Datenbank zu verwenden.

Außerdem verstehe ich nicht, warum ich den aktuellsten Wert der IDENTITY-Spalte nicht ermitteln kann, wenn der Update-Befehl mit einem CommandBuilder erstellt wurde. Die Datenbank "weiß" doch nicht, wie ich den INSERT-Befehl generiert habe.


Gruß
Frank

[Frank H]

Hallo,

mittlerweile habe ich den Fehler gefunden. Das Problem war, dass ich für den "SELECT IDENTITY"-Befehl und den CommandBuilder zwei verschiedene Connections erstellt habe. Verwendet man die selbe Connection, lässt sich auch der Primärschlüssel aus der Datenbank ermitteln.

Zu dem Problem "Master- und Detailtabelle mit CommandBuilder" habe ich folgende Lösung gefunden:
Ich filtere die hinzugefügten Masterdatensätze mit

dataSet.Mastertabelle.Select("", "", (DataViewRowState.Added));

Dann durchlaufe ich die hinzugefügten Master-Datensätze (äußere Schleife) und bestimme mit

dataSet.Mastertabelle.Select("primaerschluesselFeld = '" + prMaster.ToString() + "'");

einen hinzuzufügenden Datensatz nach dem anderen.
Nach dem Updaten dieses einen Datensatzes rufe ich die IDENTITY-Funktion der Datenbank auf und bestimme so den von der Datenbank vergebenen AUTO INCREMENT-Wert.
Als nächstes durchlaufe ich die hinzugefügten Detaildatensätze (innere Schleife) und bestimme die Datensätze, deren Wert in der Fremdschlüsselspalte mit dem des vom DataSet vergebenen Primärschlüssel-Werts übereinstimmt.
Dann muss man nur noch mit

dataSet.Detailtabelle.Select("", "", (DataViewRowState.Added))[schleifenZaehler][fremdschluesselSpalte] = identityWert;

den von der Datenbank vergebenen Primärschlüsselwert des Masterdatensatzes zuweisen.
Die hinzugefügten Detaildatensätze können dann am Schluss auf einmal per Update in die Datenbank übertragen werden.


Auf dieses Problem bin ich übrigens nur durch Zufall gestoßen. Wenn die Foreign Key-Relation im DataSet gleich wie in der Datenbank aufgebaut ist, stimmt der vom DataSet angenommene Wert der AUTO INCREMENT-Spalte ja im Normalfall mit dem von der Datenbank vergebenen Wert überein. Das Problem fällt erst auf, wenn in der Datenbank z.B. die Zeile mit dem höchsten AUTO INCREMENT-Wert gelöscht wird.


Gruß
Frank

[Andreas Kosch]

Hallo,

Verwendet man die selbe Connection, lässt sich auch der Primärschlüssel aus der Datenbank ermitteln.

aber nur dann, wenn nur ein einziger Benutzer mit der Datenbank arbeitet ;-)

Im Mehrbenutzerbetrieb wird ein "zufälliger" Wert zurückgeliefert.