Insert oder Update ?

[Hansa]

Hi,

ich sammele Eingaben in einem Stringgrid. Diese sollen zum Schluß in eine Interbase-DB rein. Nun weiß ich aber nicht, ob die entsprechenden Datensätze bereits vorhanden sind oder nicht.

Um dies herauszufinden müßte ich versuchen die einzelnen Datensätze nochmals zu lesen. Kommt als Ergebnis IsEmpty müßte ich ein Insert machen, ansonsten ein Update. Für die Eingabe in das Stringgrid muß ich ihn aber auch schon lesen. Das kommt mir etwas zu viel des guten vor. Geht das auch anders ?

Das einzige, was mir dazu noch einfällt ist, immer ein insert oder update zu machen und im Fehlerfall, das entsprechend andere. Aber irgendwie, weiß net.

[Sharky]

Zitat von Hansa:

...ich sammele Eingaben in einem Stringgrid. Diese sollen zum Schluß in eine Interbase-DB rein. Nun weiß ich aber nicht, ob die entsprechenden Datensätze bereits vorhanden sind oder nicht.....

Füllst Du das StringGrid vorher mit allen Datensätzen die schon vorhanden sind?

[Hansa]

Hai Sharky,

nein fülle ich nicht. Das wären zu viele. Es geht um Rechnungen, Preise usw. D.h. ich prüfe z.B. bei der Eingabe, ob ein entsprechender Artikel vorhanden ist. Dann gebe ich den dazu gehörigen Preis ein oder die Menge. Soll das ganze zum Schluß gespeichert werden, so sollen noch ein paar andere Tabellen aktualisiert werden.

[Sharky]

Hai Hansa,

als erstes würde mir einfallen die über das BeforPost Ereigniss zu machen. Dann musst Du allerdings immer selber prüfen ob eien Datensatz schon vorhanden ist.

Als alternative wäre es vielleicht möchglich mit einem INSERT Trigger zu arbeiten. Wenn Du in diesem dann die Prüfung machst könntest Du den vorhanden Datensatz vorher löschen. Oder eventuell sogag das INSERT in ein UPDATE umwandeln?

Ich habe noch nicht viel mit Triggern gemacht, darum bin ich mir da nicht sicher.

[Hansa]

Sharky ist da wie es aussieht ziemlich nah dran, aber das hier ist wahrscheinlich die Lösung :

Zitat von Borland:

> Whats the best way to handle this ?

I think the most elegant way would be to write an updateable VIEW (a
JOIN with the result set you need and triggers to do the
INSERTs/UPDATEs on the underlying tables). Your app simply treats the
VIEW like it was a table, and the DB server hides the implementation
details.

Views sind einige der wenigen Dinge, mit denen ich mich noch nicht beschäftigt habe. Nur, was meint der mit einem updateable VIEW ??? Und was soll das für ein JOIN sein ???

[Sharky]

Zitat von Hansa:

Views sind einige der wenigen Dinge, mit denen ich mich noch nicht beschäftigt habe. Nur, was meint der mit einem updateable VIEW ??? Und was soll das für ein JOIN sein ???

Hmmm.... Neue Datensätze in eine View einzutragen ist das schlechteste mas man machen kann!
Eine View ist ja nichts anderes als eine (Servergespeicherte) Joing.

Solltest Du in dieser z.B eine 1:n Verbindung haben und löschst jetzt die Referenz sind auch alle anderen Tabellen betroffen.

Darum war ja mein Vorschlag dies über einen Trigger zu versuchen.

[Hansa]

Meine Sicht auf die Views wird zwar langsam konkreter. Aber nur langsam. Aber wie es aussieht, wird doch mit Hilfe eines Views eine Art Hilfstabelle aufgebaut, die Spalten aus mehreren Tabellen eben in einem View zusammenführt. Und dieser View läßt sich mit select, insert, update usw. genau so behandeln, wie eine normale Tabelle. Wieso soll das so schlecht sein ?

Was ich aber nicht verstehe, wenn das hier überhaupt so stimmt: was ist bei 20 Tabellen, die in einem View gemeinsam behandelt werden sollen und 10 davon brauchen ein Insert und die übrigen ein Update

[Vermutung]Das könnte auf so was wie SELECT * FROM SELECT * FROM... hinauslaufen[/Vermutung]

[Alfons_G]

Ob man einen View updaten kann, hängt zum Einen von der Art des Views ab, zum Anderen von der Datenbank.
Viele Systeme erlauben Update- und Insert-Operationen nur auf Views, welche nur auf einer einzelnen Tabelle basieren. Bei Access kannst Du auch in Views schreiben, welche aus mehreren Tabellen zusammengesetzt sind. Bedingung ist dabei natürlich, dass sich die Felder eindeutig zuordnen lassen. Das heisst, bei einer 1:n-Verknüpfung kannst Du nur Updates auf die Felder der Tabelle durchführen, welche eindeutig sind. Access prüft das allerdings nicht so streng, so dass man unter Umständen böse Überraschungen erleben kann
Bei Oracle sind NUR VIews editierbar, deren Daten aus lediglich einer Tabelle entstammen. So vermeidet die Datenbank Performance-schluckende Überprüfungen, ob die Daten gefahrlos geändert werden können.

In dem Borland-Zitat steht auch ausdrücklich drin, dass die eigentliche Insert/Update-Operation durch einen Trigger erledigt werden soll. Vermutlich bezieht sich die Erklärung auf Interbase. Das geht aber mit jeder DB, welche Trigger beherrscht. Bei Access usw. muß man den Trigger "zu Fuß" mit einer Ereignisprozedur in Delphi nachbilden. In beiden Fällen wird dann die Schreiboperation nicht auf den View, sondern auf die zugrundeliegende Tabelle ausgeführt.

[Hansa]

Zitat von Alfons_G:

...In dem Borland-Zitat steht auch ausdrücklich drin, dass die eigentliche Insert/Update-Operation durch einen Trigger erledigt werden soll. Vermutlich bezieht sich die Erklärung auf Interbase...

Und genau das mit dem Trigger verstehe ich nicht richtig. Wie, was, wo ? Und, ja es geht um Interbase (steht ganz am Anfang).

[mschaefer]

Moin, Moin Hansa,

Die Views lasse ich mal raus, das sind vorbereitete
Abfragen um die ganzen Select-Statements nicht jedesmal neu schicken zu müssen...

Habe sowas ähnliches mal auf folgendem Weg gelöst

Delphi-Quellcode:

           if DataLink.DataSet.Locate( 'PID_Feldname', 'Mein_Wert' ,[] )
           then DataLink.DataSet.Edit
           else DataLink.DataSet.Append;

Im 'PID_Feldname' Feld der Datenbank wird hier ein eindeutiger Index erwartet.
Bei 'Mein_Wert' könntest Du auch auf die Zeilen Deinse StringGrids zugriefen. Zum Beispiel die eindeutige Artikelnummer, die sich in der Datenbank im PID_Fieldname# Feld befindet.

Grüße aus dem etwas unterkühlten Norden // Martin