UPDATE OR INSERT INTO - Problem

[himitsu]

Man könnte doch über ein SubSelect versuchen eine ID zu finden und wenn keine gefunden wurde, dann eben NULL verwenden?

Nur die Frage ist, was man für dieses SubSelect für die eindeutige Erkennug nutzt, wenn was geändert wurde

Also eigentlich sollte ja eine ID für die Eindeutigkeit da sein und wenn man einen Datensatz ändert, mußte man ihn doch vorher ausgelesen haben?
Da sollte man sich die ID gleich mitnehmen und schon gibt es beim Absenden keine Probleme mehr, mit dem Insert or Update.


Wobei ID ja aktuell noch nicht eindeutig ist. Also PrimaryKey und Co. wären da ganz angebracht.
Also dürfte hier doch immer das Insert zuschlagen, egal was man angibt, da nirgendwo eine eindeutige Kennzeichnung möglich ist?

[RWarnecke]

Guten Morgen zusammen,

erstmal danke für die vielen Antworten. Das Feld ID ist ein AutoInc und wird über einen Trigger gefüllt. Die ID vorher auszulesen und dann mitzugeben, wäre kein Problem. Das werde ich heute Abend mal ausprobieren.

Ein geteiltes Update und Insert wollte ich eigentlich gerne vermeiden. Deshalb habe ich den Befehl UPDATE OR INSERT gewählt.

Wenn ich einen Primary Key setze, könnte ich doch mir die MATCHING-Anweisung sparen ? Oder muss ich die Anweisung trotzdem benutzen ?

[DeddyH]

In der MATCHING-Klausel gibst Du ja die Felder an, die einen Datensatz eindeutig identifizieren (sollen). Wenn sich nun also der Nachname ändert und dieser Teil der MATCHING-Klausel ist, wird logischerweise ein neuer Datensatz angelegt. Wenn Du nun irgendein Feld/eine Kombination von Feldern als UNIQUE deklarieren kannst, bietet sich dieses dann auch als Kandidat für die MATCHING-Klausel an.

[ChrisE]

Hallo RWarnecke,

ja, sobald du die ID hast bei der du den Eintrag ändern will reicht das ohne MATCHING. Um zu vermeiden, dass du zwei Statemants brauchst, könntest du dort in den Code einbauen, dass der Paramterwert für ID auf NULL gesetzt wird, wenn ein neuer Datensatz gemacht / erstellt wird. Sowas in der Art von:

Delphi-Quellcode:

if theID <> -1 then
begin
  ParamByName('ID').AsInteger := theID;
end else
begin
  ParamByName('ID').Clear;
end;

Gruß, Chris

[Neumann]

Denke, dass hier 2 Tabellen gebraucht werden, also eine mit den Kunden-Basisdaten (Adresse, Bank usw). Daraus kann man dann die KundenNr als Fremdschlüssel verwenden.

Außerdem würde ich "Update or Insert" bei der direkten Bearbeitung der D nicht verwenden. Entweder ändern oder neu, das sollte der Bearbeiter entscheiden. Die Nr für den Ansprechpartner kann automatisch über den Trigger generieren. Ein Primärschlüssel auf AnsprechpartnerNr würde die Sache dann noch perfekt machen.