UPDATE OR INSERT INTO - Problem

[RWarnecke]

Hallo zusammen,

mit dem folgenden Quelltext füge ich neue Datensätze hinzu oder ändere diese.

Delphi-Quellcode:

  with UniQuery_Ansprechpartner do
  begin
    SQL.Clear;
    SQL.Add('UPDATE OR INSERT INTO');
    SQL.Add('Ansprechpartner (Kundennr, Vorname, Nachname, Telefon1, Telefon2, Fax, Mobil, EMail)');
    SQL.Add('VALUES (:Kundennr, :Vorname, :Nachname, :Telefon1, :Telefon2, :Fax, :Mobil, :EMail)');
    SQL.Add('MATCHING (Kundennr, Vorname, Nachname)');
    ParamByName('Kundennr').AsString := Klasse.KundenNr;
    ParamByName('Vorname').AsString := Klasse.Vorname;
    ParamByName('Nachname').AsString := Klasse.Nachname;
    ParamByName('Telefon1').AsString := Klasse.Telefon1;
    ParamByName('Telefon2').AsString := Klasse.Telefon2;
    ParamByName('Fax').AsString := Klasse.Fax;
    ParamByName('Mobil').AsString := Klasse.Mobil;
    ParamByName('EMail').AsString := Klasse.EMail;
    Execute;
  end;

Nur bei der Änderung gibt es ein kleines Problem. Wenn ich jetzt den Nachnamen ändern muss, wird ein neuer Datensatz angelegt mit dem neuen Namen und der alte Datensatz bleibt bestehen. Da ich in der Tabelle keinen Index habe, ist dafür aus meiner Sicht der MATCHING-Teil schuld. Jetzt ist die Frage, wie kann ich es trotzdem realisieren, dass im bestehenden Datensatz der Nachname oder Vorname geändert werden kann ?

Meine Tabelle sieht so aus :

Code:

/******************************************************************************/
/****                                Tables                                ****/
/******************************************************************************/


CREATE GENERATOR GEN_ANSPRECHPARTNER_ID;

CREATE TABLE ANSPRECHPARTNER (
    ID        INTEGER NOT NULL,
    KUNDENNR  VARCHAR(15) NOT NULL,
    VORNAME   VARCHAR(50) NOT NULL,
    NACHNAME  VARCHAR(75) NOT NULL,
    TELEFON1  VARCHAR(30),
    TELEFON2  VARCHAR(30),
    FAX       VARCHAR(30),
    MOBIL     VARCHAR(30),
    EMAIL     VARCHAR(100)
);




/******************************************************************************/
/****                               Triggers                               ****/
/******************************************************************************/


SET TERM ^ ;



/******************************************************************************/
/****                         Triggers for tables                          ****/
/******************************************************************************/



/* Trigger: ANSPRECHPARTNER_BI */
CREATE OR ALTER TRIGGER ANSPRECHPARTNER_BI FOR ANSPRECHPARTNER
ACTIVE BEFORE INSERT POSITION 0
as
begin
  if (new.id is null) then
    new.id = gen_id(gen_ANSPRECHPARTNER_id,1);
end
^


SET TERM ; ^

[mkinzler]

Das matching zeigt ja an, wann ein neueinzufügender Datensatz als vorhandener erkannt wird. In deinem Fall sollte doch Kundennr als alleiniger Wert schon für Eindeutigkeit ausreichen.

[RWarnecke]

Hallo Markus,

nein, Kundennr reicht nicht als alleiniger Wert aus, da es für eine Kundennummer auch mehrere Ansprechpartner geben kann.

[haentschman]

Hallo...

in deinem Falle ohne ID nicht möglich.

Zitat:

Jetzt ist die Frage, wie kann ich es trotzdem realisieren, dass im bestehenden Datensatz der Nachname oder Vorname geändert werden kann ?

... in dem du selbst entscheidest ob Insert oder Update und getrennte Statements absetzt.

[FredlFesl]

Wie mein Vorredner schon sagte, benötigst Du zur Unterscheidung, was den die Eindeutigkeit eines Ansprechpartners ausmacht, die "ID" als Kriterium. Dafür ist sie schließlich gedacht (mir fehlt allerdings noch das PK-Contstraint in der Tabellendefinition).

[ChrisE]

Hi,

muss der Anwender nicht um etwas zu ändern den Ansprechpartner / also den Datensatz erstmal aus einer Liste wählen? Dann hättest du doch alle Daten für Dein Update.
Er müsste dann nur einen Datensatz wählen für eine Änderung oder einen "Knopf" o.ä. für einen neuen Datensatz drücken. Kenn ich in fast allen Datenverarbeitungsanwendungen so. Wäre also meines Erachtens nicht schlimm. Aber ich kenne den genauen Anwendungsfall auch nicht.
Was für ein quatsch am Montag morgen :-) Sorry - war noch nicht richtig wach :-)

Gruß, Chris

[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 :gruebel:

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.

[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.