SQL CREATE or Replace View

[B.Hauser]

ich weiß nicht wo Du nachschaust, aber die Website, die Referenzen und sonstige Handbücher werden eigentlich immer mit oder kurz nach dem TR Announcement angepasst.
Zumindest war das so mit den letzten paar Erweiterungen.

CREATE OR REPLACE ist beschrieben! Aber man bekommt vielleicht nicht alles kleingekaut, man muss auch ein bißchen mitdenken und Schlussfolgerungen ziehen.
Ich habe genauso viel oder wenig Zugriff auf die TR Beschreibungen wie andere auch, meine Quellen sind ausschließlich das Internet.

Ansonsten kann man die Erweiterungen immer unter den Technologie Updates finden

Eine Konvertierung eines numerischen Wertes mit CHAR wurde noch nie empfohlen, da CHAR führende Nullen entfernt und linksbündig ausrichtet und den Rest mit BLANKS auffüllt!
Eine Multiplikation zur Konvertierung von numerischen Datums-Werten war ebenfalls noch nie empfohlen, da es hierbei zu Überläufen kommen kann!
Desweiteren ist es nichts Neues, dass eine Zahl ohne Dezimal-Positionen mutliplizert mit einer anderen Zahl in Dezimal-Positionen ein Ganzzahliges Ergebnis liefert. Ob das Ergebnis dann als Integer oder BigInteger ausgegeben wird hängt dann von den tatsächlichen Ergebnis ab, aber wie bereits bemerkt kann es hierbei zu Überlaufen kommen.
Die Empfehlung war schon immer die Konvertierung mit DIGITS zu manchen und dann einen String bestehend aus 6 Nullen dazuzuketten.

DIGITS und CONCAT haben schon immer funktioniert unter allen Releasen und allen TRs.

Birgitta

[BenderD]

... deshalb empfehle ich, das ganze TR Gedöns als "technical preview" zu sehen und in production nicht zu verwenden und stets abzuwarten bis es in einem Release enthalten ist. In vielen Fällen handelt es sich bei Neuereungen ohnehin um Schnickschnack, den man nicht verwenden sollte, wenn er nicht SQL Standard ist. In diese Ecke gehören fast alle UDTFs, die von IBM und einigen blaugestreiften Apologeten angeboten werden wie Sauerbier.
Eine Bemerkung noch zur Prüflogik von numerischen Operationen: Hintergrund sind hier Änderungen in der Implementierung numerischer Operationen, weg von packed decimal arithmetic, die Overflow conditions oft erst zum Schluss erkannt hat.
Hinterher ist es immer leicht zu sagen, hätte man das früher besser gemacht, hätte es heute nicht geknallt, der Compiler war halt zu lax. Keiner hält sich an alle Regeln, die der Compiler nicht prüft, aber prüfen könnte (siehe Variablennamen in embedded SQL). Was ich erwarten würde, wäre, dass man verschärfte Prüflogik beim Compile abschalten könnte (ähnlich TGTRLS).

D*B