Zitat Zitat von BenderD Beitrag anzeigen
... das ist einfach zu beantworten:
values into ist kein SQL Standard, zudem ist die standard Version mit cursor im Fehlerfall einfacher zu behandeln - sprich defensiver. Das ist Dir aber vermutlich egal, Du empfiehlst ja auch naming *sys, commit(*none) und Datenschrank Verarbeitung nach LIBL - ich empfehle halt was anderes, lass doch jeden selbst entscheiden.

D*B
Dieter,

Ich hab' langsam die Schnautze voll!
Was sollen diese ständigen Angriffe!
Jedes Mal wenn ich etwas schreibe, versuchst Du mir mit unqualifizierten und unwahren Behauptungen an den Karren zu fahren.

Ich gehe von der Ausgangssituation aus und die ist hier nun mal so, dass viele weder unter Commit fahren und außerdem Ihre Daten in unterschiedlichen Bibliotheken hinterlegt haben.

SELECT ... INTO und VALUES ... INTO generieren beide im Untergrund einen Cursor, Öffnen diesen, Lesen den ersten Satz und schließen den Cursor wieder. Warum also 5 Statements schreiben, wenn es auch 2 tun. Im Fehlerfall wird jeweils ein SQLCODE (oh' Verzeihung ist ja nicht Standard!!!) und ein SQLSTATE ausgegeben, die abgeprüft werden können.

Desweiteren bin ich mit Sicherheit die letzte, die COMMIT *NONE empfiehlt. Gerade Journaling und Commitment-Control ist eines der Themen, die ich grundsätzlich empfehle!

Was die Namenskonventionen angeht, so überlasse ich das jedem selber. NUR sollte man wissen welche Konsequenzen dahinter stecken, wenn man statt System- SQL-Naming verwendet. Das erkläre ich auch immer und das ist weit mehr als das Trennkennzeichen zwischen Schema und Objekt (wobei beim System-Naming inzwischen auch der Punkt als Trennzeichen verwendet werden kann).

Ich denke das war jetzt wohl endgültig das letze Mal, das ich in diesem Forum irgendetwas gepostet habe.

Birgitta