Einspruch euer Ehren, in mehreren Punkten:

ad Formatnamen: der ist für SQL Zugriffe völlig Banane

ad select *: der * wird beim Compile aufgelöst, sprich das läuft bei zusätzlichen Feldern unverändert weiter; bei der nächsten Änderung (sprich recompile) wird das zusätzliche Feld erst sichtbar.

ad Sperren: beim Update nach Cursor sperrt DB2/400 den zuletzt gelesenen Satz auch ohne Commit, das läuft dann ziemlich analog zu Rekord Löffel.

ad Commit Level: bei korrektem Einsatz wird hier vieles möglich, was bei Rekord Löffel Ekzem garnicht geht. Zum Beispiel konsistente Auswertungen während laufender Transaktionen (gerade weil es hier Sperren gegen lesen gibt) - mit Rekord Löffel Ekzem kann man nicht sicher stellen, dass eine Saldenübersicht im Tagesbetrieb ausgeglichenen Saldo liefert.

ad Tipparbeit: bei voller Nutzung von SQL hört das Sätze zusammen klappern (read, setll, reade, Schlüssel besetzen, chain, Schlüssel besetzen chain...) auf und die Tiparbeit nimmt drastisch ab!

ad laufende Nummern: dafür gibt es extra einen Feldtyp mit AUTOINCREMENT, da gibt es im Programm nix zu tippen.

mfg

Dieter Bender,

der in einem völlig übereinstimmt: ohne Umdenken im Anwendungsdesign und ohne solide Kenntnisse wird das eher nix.


Zitat Zitat von Fuerchau Beitrag anzeigen
Über eins sollte man sich im Klaren sein:
Bei SQL ist mehr Definitions und Tiparbeit gefragt, wenn man's denn richtig machen will.

Dateien, die per CREATE TABLE erstellt werden, erhalten als Formatnamen den Namen der Tabelle.

Man sollte nie "SELECT *" verwenden, da sonst eben wieder mehrfach umgewandelt werden muss (Tiparbeit).

Normalerweise sperrt ein SELECT nie !!!
Also Vorsicht bei UPDATE (neues Konzept) !
Um Sperren beim SELECT zu erhalten, hilft nur Journaling und CMTLVL(*ALL), was allerdings immer noch nicht das Lesen durch andere Programme verhindert.

Neue Daten können nur per INSERT erstellt werden, auch hier ist Tiparbeit wieder gefragt.

Da beim INSERT jedoch nicht immer alle Felder benannt werden müssen, ist beim CREATE TABLE über NULL-Werte bzw. Defaults nachzudenken, ggf. sind Trigger nötig.

Häufig werden für laufende Nr'n einfach CHAIN/ADD 1/UPDAT kodiert, das funktioniert so nicht mehr sicher.
Hier sind ggf. Generatoren nötig bzw. eben neue Konzepte.

Es gibt da sicherlich noch viele weitere Punkte, jedoch ist eins sicher:
SQL erfordert ein Redesign einer Anwendung, da sonst unerwartete Ergebnisse sehr wahrscheinlich werden.