SQL - Create Table X/Y Angabe Satzformat

[JonnyRico]

Danke ihr beiden für die fixe Antwort. Dann mache ich das so. Danke und schönes Wochenende.

Gruß

Sascha

[Fuerchau]

@Dieter
Damit erspare ich mir das dauernde Umbenennen in RPG

Allerdings: Warum mache ich CREATE TABLE um anschließend in RPG doch wieder native zuzugreifen ? *grübel*

[BenderD]

@Baldur,

da kann man doch alternativ auf das E (extern definiert) in der F Lochkarte verzichten eine EDS separat ablochen und mit
read Dateiname Datenstrukurname
die Daten schnappen, oder was sagen die RPG Hardliner dazu?
Den Scharmonz mit read Formatname, den habe ich eh nie verstanden, jaja ich weiß, MultiFormat Dateien, aber die habe ich auch nicht verstanden.

Dieter

@Dieter
Damit erspare ich mir das dauernde Umbenennen in RPG

Allerdings: Warum mache ich CREATE TABLE um anschließend in RPG doch wieder native zuzugreifen ? *grübel*

[Fuerchau]

RPG lehnt die Umwandlung ab, da der Name nicht eindeutig ist.
Es gibt immerhin noch DSPF's und PRTF's (multiple Formate).

Der Compiler unterscheidet da leider nicht.

[BenderD]

@Baldur: wenn ich unter Dateiformat kein E für extern beschrieben, sondern ein F für Programm beschrieben abloche, dann ist dem Compiler der Formatname schnurz. DSPF und PRTF werden nicht mit SQL erstellt und damit tritt sowas hier nicht auf.

Dieter

RPG lehnt die Umwandlung ab, da der Name nicht eindeutig ist.
Es gibt immerhin noch DSPF's und PRTF's (multiple Formate).

Der Compiler unterscheidet da leider nicht.

[B.Hauser]

Allerdings: Warum mache ich CREATE TABLE um anschließend in RPG doch wieder native zuzugreifen ? *grübel*

1. CREATE TABLE, um z.B. eine IDENTITY COLUM oder ROWID zu definieren, die beim Erstellen einen eindeutigen Wert generieren und zwar auf einem tieferen Level und sicherer als das eine RPG-Funktion könnte. Das Generieren dieser Werte klappt auch, wenn man mit native RPG einen gewöhnlichen WRITE absetzt.

2. Native RPG, weil ein CHAIN halt immer noch schneller ist, als das entsprechende Statement mit SQL auszuführen.

Birgitta

[BenderD]

Hallo,

nicht alles was Oracle macht muss es wert sein in DB2 gekupfert zu werden. Ob diese Identity Columns halten was sie versprechen, habe ich noch nicht gesehen und das hat ja immerhin den Nachteil, dass ich nicht so ohne weiteres den Satz lesen kann, den ich gerade geschrieben habe. (Ja, ich weiß, dass es da einen Work around gibt...). Ein anderer dieser "Geheimtips", das API GENUUID jedenfalls hielt garnicht, was es versprach, funktioniert nämlich bei Multiprozessor Maschinen nur fast - und damit garnicht.
Und was die Geschwindigkeit angeht, oft gehört, aber - in erster Näherung hängt die Geschwindigkeit von der Anzahl der Zugriffe ab und da sind viele Rekord Löffel Exzess Programme eher Penner als Renner.


mfg

Dieter Bender

PS: Bei der gegenwärtigen Menge an Bugs in der Datenbank würde ich die Schlüssel Generierung nur ungern der Datenbank überlassen...

1. CREATE TABLE, um z.B. eine IDENTITY COLUM oder ROWID zu definieren, die beim Erstellen einen eindeutigen Wert generieren und zwar auf einem tieferen Level und sicherer als das eine RPG-Funktion könnte. Das Generieren dieser Werte klappt auch, wenn man mit native RPG einen gewöhnlichen WRITE absetzt.

2. Native RPG, weil ein CHAIN halt immer noch schneller ist, als das entsprechende Statement mit SQL auszuführen.

Birgitta

[Fuerchau]

@Dieter
Interne Dateien aber dann externe Strukturen ??

@Birgitta
Dass ein CHAIN noch schneller sein soll als ein Select, halte ich für ein Gerücht.
Was ich in RPG mit mehreren native-Befehlen machen muss, erledige ich häufig mit einem SQL.
Das mit der Performance war mal so bei V3 !

[BenderD]

Hallo,

genau das!!! damit hört der Quatsch des impliziten Füllens auf etc... Ich kann genau sagen wohin ich lesen will und aus was ich füllen will - das ist um Längen lesbarer- denk mal drüber nach.
Zu den Performance Geschichten: nach meinen Erfahrungen ist record level access bezogen auf eine Einzeloperation immer noch schneller als SQL, obwohl IBM von Release zu Release seit V4 das Gegenteil behauptet, da handelt es sich wohl um Wunschdenken aber: bezogen auf reale Programme ist SQL im Schnitt schneller und ich biete folgendes an:
jedes Batchprogramm, das mehr als 30 Minuten läuft und Rekord Löffel Exzess benutzt, mache ich mit SQL schneller, wenn die Maschine genug freie Ressourcen hat, erreiche ich das Ziel nicht, ist mein Bemühen kostenlos. (Habe ich auch mal für Java im Batch schneller als RPG angeboten).

mfg

Dieter Bender

@Dieter
Interne Dateien aber dann externe Strukturen ??

@Birgitta
Dass ein CHAIN noch schneller sein soll als ein Select, halte ich für ein Gerücht.
Was ich in RPG mit mehreren native-Befehlen machen muss, erledige ich häufig mit einem SQL.
Das mit der Performance war mal so bei V3 !

[holgerscherer]

@Birgitta
Dass ein CHAIN noch schneller sein soll als ein Select, halte ich für ein Gerücht.
Was ich in RPG mit mehreren native-Befehlen machen muss, erledige ich häufig mit einem SQL.
Das mit der Performance war mal so bei V3 !

**snip**

Och... auch eine V5-Kiste kriege ich mit RPG oder SQL sehr schnell langsam ;-)

Besonders zu beachten ist der gelegentliche Unterschied, wie ein RPG-gewohnter Programmierer sich ein SQL Statement zusammenlötet und dann nicht beachtet, was der gelobte (sic) Optimizer daraus treibt. Ich kann nur eine Lehrstunde mit den Performance-Tools und dem Advisor im OopsNav5.3 empfehlen, auch wenn sonst im V5R3 einige Kataströfchen enthalten sind.

Übrigens schliesse ich mich hier mal Dieters Performance-Aussage an, das kann sogar für das interpretierte Net.Data gelten, wenn man hier optimiert.

Und letztendlich ist Ausführungsgeschwindigkeit auch nicht immer alles. Da bastelt man tagelang um ein interaktives RPG-Programm zum fliegen zu bekommen, und wenn es dann Reisegeschwindigkeit erreicht hat, kommt Herr Interaktivwächter und haut dem Programm eins auf die Fr^h^hNase.
Währenddessen läuft ein Net.Data- oder sonstwieinsbatchgehobene Programm gemütlich aber zügig daran vorbei.

Ich bin ja auch eher ein Freund der grün-auf-schwarzen, aber hier muss man leider der Realität ins Auge sehen.

Übrigens: Wer eine zufällig zwei Maschinen (V5R2 und V5R3) hat, kann ja mal parallel auf beiden Kisten etwas interaktive Last ausprobieren und mit WRKSYSACT sich verlustieren.

Besonders lustige Ergebnisse gibt ein interaktives STRSQL bei parallelem INSERT INTO blubb SELECT * FROM irgendwo ;-)

[Hartgesottene blättern parallel wild im DSPLOG rum]

-h

[Fuerchau]

Was mir bei SQL native noch fehlt, ist die gleiche Möglichkeit wie bei SQLCLI, den SQL-Prozess als Hintergrundprogramm (QSQSRVR) zu aktivieren. Damit lege ich dann eine nicht unerhebliche Last in Batch.

Kennt jemand da eine Lösung ?

[BenderD]

@Baldur: Diese Lösung ist elementar: Zwei Maschinen sind billiger als eine!!!
- Alle Zugriffe per SQL, Rekord Löffel Exzess komplett ablösen
- eine kleine 250 oder so, für 5250, eine (5)250 sozusagen.
- jetzt darf man von der (5)250 auf die richtige AS400, den Datenbankserver connecten und ist dort im Batch.

Dieter Bender

Was mir bei SQL native noch fehlt, ist die gleiche Möglichkeit wie bei SQLCLI, den SQL-Prozess als Hintergrundprogramm (QSQSRVR) zu aktivieren. Damit lege ich dann eine nicht unerhebliche Last in Batch.

Kennt jemand da eine Lösung ?