Update einer SQL-Abfrage über Tabelle mit mehreren Feldern im Primärindex

[Elerian Heine]

Ich habe folgendes Problem:

Ich hole mir Daten aus einer Paradox-Tabelle über eine simple SELECT-Abfrage zum Editieren.

<font size=-1><PRE>SELECT kundennr, image, name1, name2, land, plz, ort, strasse
FROM kunden
WHERE kundennr=12345</PRE></font>

Das UpdateObject der Query, eine TUpdateSQLKomponente, enthält folgende SQL-Anweisung im ModifySQL:

<font size=-1><PRE>UPDATE KUNDEN
SET
name1 = :name1,
name2 = :name2,
land = :land,
plz = lz,
ort = rt,
strasse = :strasse
WHERE
(kundennr = :OLD_kundennr) and
(image = :OLD_image) and
(name1 = :OLD_name1) and
(name2 = :OLD_name2) and
(land = :OLD_land) and
(plz = :OLD_plz) and
(ort = :OLD_ort) and
(strasse = :OLD_strasse)</PRE></font>

Der WHERE-Teil ist deshalb so lang, weil die Tabelle <b>alle dort aufgeführten Felder als Primärindex</b> verwendet.

Das Problem:

Die SQL-Anweisung funktioniert solange alle Felder <> NULL sind auch prächtig.
Sobald aber ein Feld zb. Ort = NULL ist, dann erscheint Delphi mit der Fehlermeldung: "Aktualisierung mißlungen."

Also habe ich die SQL-Anweisung im ModifySQL etwas geändert:

<font size=-1><PRE>UPDATE KUNDEN
SET
name1 = :name1,
name2 = :name2,
land = :land,
plz = lz,
ort = rt,
strasse = :strasse
WHERE
(kundennr = :OLD_kundennr) and
(image = :OLD_image) and
(name1 = :OLD_name1) and
((name2 = :OLD_name2) OR (name2 IS NULL)) and
((land = :OLD_land) OR (land IS NULL)) and
((plz = :OLD_plz) OR (plz IS NULL)) and
((ort = :OLD_ort) OR (ort IS NULL)) and
((strasse = :OLD_strasse) OR (strasse IS NULL))</PRE></font>

Das Ergebnis war nun das der entsprechende Datensatz geändert wurde, jedoch auch das <b>AUTOINC</b> - Feld (hier: kundennr) erhöht wurde
und das sollte <b>nicht</b> passieren!
Dies wirkt sich natürlich nachteilig auf eine Masterdetail-Bezeihung aus.

Gibt es da irgendeine Möglichkeit dieses Problem zu lösen?

Danke im Vorraus...

Elerian.

[Andreas Kosch]

Hallo,

immer dann, wenn Paradox beim UPDATE-Aufruf der Wert einer AUTOINC-Spalte erhöht, wird von der BDE intern der "alte" Datensatz gelöscht und durch den neu eingefügten Datensatz ersetzt.

Ein Primärschlüssel einer Tabelle hat die Aufgabe, einen Datensatz logisch eindeutig zu kennzeichnen. Wenn ein AUTOINC-Feld im Primärschlüssel verwendet wird, macht es keinen Sinn, zusätzliche Spalten hinzuzufügen, da diese zusätzlichen Spalten für die logische Eindeutigkeit nicht benötigt werden. Statt dessen wäre ein zweiter UNIQUE INDEX für die restlichen Spalten (ausser dem AUTOINC-Feld) die bessere Idee gewesen, um das Anlegen von doppelten Kundendaten zu verhindern.

Anscheinend rechnet die BDE nicht mit derart "komischen" Tabellen, so dass der alte Datensatz über den logisch eindeutigen AUTOINC-Wert gelöscht und dann ein neuer Datensatz angelegt wird. Es wird wohl nichts anderes übrigbleiben, als jeden UPDATE-Vorgang in beiden Varianten zu probieren. Geht der erste Aufruf schief (wegen NULL), muss die Exception abgefangen und der zweite UPDATE-Aufruf probiert werden