Return ILE RPG

[Squall]

Ein Array ist da nicht so gut, da
1. sehr große Datenmengen übergeben werden
2. die Anzahl der Sätze ja nicht bestimmbar ist.

Wenn du also ein Array mit 100 Einträgen als Return definierst werden immer 100 Einträge zurückgegeben, auch wenn vielleicht gar keine Daten vorliegen.

Besser ist da eine Satzweise Übergabe wobei das auch nicht so optimal ist.

Ich sehe, dass VARPG da wohl doch nicht so die beste Lösung ist.
Entweder brauche ich DB2/Connect für direktes SQL oder ich verwende weiter RecordLevel-Access (was wohl keine weitere Lizenz erfordert?).

Satzweise Übergabe klingt sehr gut nur wie mache ich das? Bei einem return wird doch aus dem Programm(RPG) herausgegangen oder nicht?

Oder ist es einfach ein:

"do *hival
fetch into ...
return
enddo" ?

Martin

PS: Es muss VARPG sein. Und wie Sie vtl aus meinem anderen Thread bemerkt haben schaffe ich es nicht von VARPG mit emb. SQL auf die AS400 zu gehen bzw dort aus der Tabelle meine Daten zu lesen.

[Fuerchau]

Dann verwende doch einfach F-Bestimmungen, VARPG erledigt das dann schon von selber.

Ansonsten gilt eigentlich folgendes:
Bei Return entscheidet *INLR über den Zustand des Programmes:
*OFF -> alle Zustände bleiben erhalten
*ON -> alles wird freigegeben, der nächste Call ist wie neu

Also kannst du durchaus Funktionsparameter wie OPEN/READ/CLOSE usw. übergeben und im Programm entsprechend reagieren.

Aber wie gesagt, verwende doch ganz einfach F-Bestimmungen und stinknormale READ/WRITE/SETLL's usw.

[Squall]

Dann verwende doch einfach F-Bestimmungen, VARPG erledigt das dann schon von selber.

Ansonsten gilt eigentlich folgendes:
Bei Return entscheidet *INLR über den Zustand des Programmes:
*OFF -> alle Zustände bleiben erhalten
*ON -> alles wird freigegeben, der nächste Call ist wie neu

Also kannst du durchaus Funktionsparameter wie OPEN/READ/CLOSE usw. übergeben und im Programm entsprechend reagieren.

Aber wie gesagt, verwende doch ganz einfach F-Bestimmungen und stinknormale READ/WRITE/SETLL's usw.

Erstmal Danke für die Hilfe.

Nun meiner Meinung nach ist das SQL "schöner" und wahrscheinlich auch schneller. Ich mache einen Select der über X Tabellen geht und muss mich nicht durch 10 Dateien hangeln was das Programm doch etwas unübersichtlich macht. Und mit einer Where Bedingung kann ich auch ein die Lösungsmenge beschränken ohne das das Feld ein keyfld sein muss bzw ich die ganze Datei seq. durchlesen muss und immer mit if schauen muss ob ein nicht-keyfld einen bestimmten Wert hat.(setll geht doch nur mit einer Keylist und dementsprechenden Keyfeldern oder?)

EDIT: Das Wichtigste vergessen...
Dh wenn ich am Anfang *inlr auf *off setze und einen return mache, muss ich das Programm nocheinmal aufrufen. Aber dann wird mein Select doch nochmal ausgeführt und dadurch mein Cursor wieder überschrieben und ich bekomme Satz 1 noch einmal. Oder muss ich das alles über Schaltvariablen abfangen?

Martin

[Fuerchau]

Du hast es erkannt.
Schalter sind da allerdings ggf. nicht ausreichend sonder ein zusätzlicher Funktionsparameter für die Steuerung:
OPEN => Cursor öffnen
FETCH => Satz übergeben
CLOSE => Curso schließen
Mit Statusrückgabe ob erfolgreich (am besten gleich den SQLCOD).

Klar ist SQL schöner, wenn aber der Einsatz des Programmes später an der Laufzeitlizenz scheitert, muss man halt nach einer besseren Lösung suchen.

[Squall]

Ist SQL denn nicht schneller als das Lesen mithilfe von Setll, read und Co.?

Die Frage für mich wäre jetzt noch:

Ich habe zb 3 Tabellen:

TABA       TABB      TABC
NAME       FNAME     ONAME
           NNAME     Wert 

Hierbei gilt die 1. Felder sind als "K" Felder definiert. NNAME ist ein normales Feld. Name = NNAME udn FNAME = ONAME. Ich will an den Wert und habe nur NAME. Ein Setll scheitert doch da NNAME kein Keyfield ist. Dh. ich muss die ganze Datei durchlesen und mit if überprüfen. Oder geht das noch anders?

Martin

[Fuerchau]

By Design: Für jeden Zugriff einen Index (LF), gilt übrigens auch für SQL, denn der ist dann noch schneller.

[Squall]

By Design: Für jeden Zugriff einen Index (LF), gilt übrigens auch für SQL, denn der ist dann noch schneller.

Ich werds erstmal über ein LF mit Joins probieren. Dann hab ich im Grunde auch nur eine Datei zum Lesen.

[B.Hauser]

Ich werds erstmal über ein LF mit Joins probieren. Dann hab ich im Grunde auch nur eine Datei zum Lesen.

Wenn Du dabei an DDS beschriebene logische join files denkst, vergiss es!
Wenn Du dabei an SQL views denkst ist das in Ordnung.

Zur näheren Erklärung. SQL verwendet immer direkt die physischen Dateien. Zugriffs-Wege (geschlüsselte logische Dateien und SQL Indices) werden intern benutzt um möglichst schnell auf die Daten zugreifen zu können. Welcher Zugriffsweg verwendet wird, entscheidet der Query Optimizer.

SQL Indices können im Gegensatz zu geschlüsselten logischen Dateien nicht in einem SQL-Statement angegeben werden.
Werden DDS beschriebene logische Dateien angegeben, löst der Optimizer die logischen Dateien auf, d.h. das SQL-Statement wird basierend auf den physischen Dateien mit der Feld-Auswahl, Join-Anweisungen und Select/Omit-Anweisungen (als Where-Bedingungen) neu geschrieben.
Erst im Anschluss ermittelt der Optimizer die optimalen Zugriff-Wege und zwar einen eigenen für jede verknüpfte physische Datei (Tabelle).

Die Auflösung der DDS-beschriebenen Dateien kann nur durch die alte (classic) Query Engine (CQE= erfolgen. Allein das Rerouting von der neuen SQL-Query-Engine (SQE) zur CQE kann bis zu 10% Performance-Einbußen mit sich bringen.

Abfragen die durch die SQE verarbeitet werden, sind z.T. wesentlich schneller als Abfragen, die durch die CQE verarbeitet werden.

Ausserdem wurden in den letzten Releasen Neuerungen in SQL eingeführt, z.B. EXCEPT, INTERSECT, OLAP-Ranking-Funktionen und rekusrive Abfragen, die NUR durch die SQE verarbeitet werden können.

Birgitta

[Squall]

Wenn Du dabei an DDS beschriebene logische join files denkst, vergiss es!
Wenn Du dabei an SQL views denkst ist das in Ordnung.

Zur näheren Erklärung. SQL verwendet immer direkt die physischen Dateien. Zugriffs-Wege (geschlüsselte logische Dateien und SQL Indices) werden intern benutzt um möglichst schnell auf die Daten zugreifen zu können. Welcher Zugriffsweg verwendet wird, entscheidet der Query Optimizer.

SQL Indices können im Gegensatz zu geschlüsselten logischen Dateien nicht in einem SQL-Statement angegeben werden.
Werden DDS beschriebene logische Dateien angegeben, löst der Optimizer die logischen Dateien auf, d.h. das SQL-Statement wird basierend auf den physischen Dateien mit der Feld-Auswahl, Join-Anweisungen und Select/Omit-Anweisungen (als Where-Bedingungen) neu geschrieben.
Erst im Anschluss ermittelt der Optimizer die optimalen Zugriff-Wege und zwar einen eigenen für jede verknüpfte physische Datei (Tabelle).

Die Auflösung der DDS-beschriebenen Dateien kann nur durch die alte (classic) Query Engine (CQE= erfolgen. Allein das Rerouting von der neuen SQL-Query-Engine (SQE) zur CQE kann bis zu 10% Performance-Einbußen mit sich bringen.

Abfragen die durch die SQE verarbeitet werden, sind z.T. wesentlich schneller als Abfragen, die durch die CQE verarbeitet werden.

Ausserdem wurden in den letzten Releasen Neuerungen in SQL eingeführt, z.B. EXCEPT, INTERSECT, OLAP-Ranking-Funktionen und rekusrive Abfragen, die NUR durch die SQE verarbeitet werden können.

Birgitta

Ich wollte über read setll etc dieses LF lesen. So würde ich es mir sparen 3-4 Dateien einzeln zu lesen. Soweit ich das oben verstanden habe sollte man nur mit SQL nicht auf diese LFs gehen, da man starke Performanceeinbußen hinnehmen müsste. Aber steht dem lesen über read etwas im Wege?

Martin

[Fuerchau]

Nein, natürlich nicht.
SQL interessiert sich nur indirekt für LF's und optimiert da manchmal selbstständig herum.
Ich habe es leider schon des öfteren erlebt, dass ich eine Join-LF mit Schlüssel performant per SETLL/READ verarbeiten kann, aber sobald ich mit SQL daran gehe habe ich Performance-Engpässe.
Klar bilde ich die Join als SQL-View nach, aber die kann keinen Index wie die Join-LF haben. Leider kommt der Optimizer nicht zu dem Ergebnis den ich mit der Join-LF vorschlage.
Was bleibt ?
Verarbeitung halt über SETLL/READ, da SQL hier einfach streikt.

Was deine Verarbeitung über F-Bestimmungen angeht, so scheinst du da eben keine Laufzeitlizenz für SQL zu benötigen.
Die F-Bestimmungen sind eben was speziefisches der AS/400 (naja RPG) und werden intern glaube ich über DDM-Dienst aufgelöst.

[Squall]

Ok danke.

Martin .

[BenderD]

@ Birgitta,

ich kann deine Begeisterung für die neue Query Engine ü b e r h a u p t
nicht teilen, die hat einen Hang zu full table scans, insbesondere bei vorhandenem parallel Database Feature und trifft teilweise katastrophale Entscheidungen. Beim Join von einer Table mit 3 Sätzen mit einer anderen mit 490 Millionen Sätzen über den Mandanten Key (dec 3 0) stellt sie den Boliden links hin und macht dort einen full table scan (um 35 Millionen Treffer zu finden) damit sie die drei Sätze nach Index verarbeiten kann; selbst wenn ich von den 3 Sätzen 2 lösche, wird dieser Satz per Index verarbeitet!?!?
BTW. hast du schon mal gesehen, dass ein EVI verwendet wird??? ich nicht!!! und die Empfehlung selbigen vor updates zu löschen und hinterher wieder zu erstellen - rührend.

mfg

Dieter Bender

Wenn Du dabei an DDS beschriebene logische join files denkst, vergiss es!
Wenn Du dabei an SQL views denkst ist das in Ordnung.

Zur näheren Erklärung. SQL verwendet immer direkt die physischen Dateien. Zugriffs-Wege (geschlüsselte logische Dateien und SQL Indices) werden intern benutzt um möglichst schnell auf die Daten zugreifen zu können. Welcher Zugriffsweg verwendet wird, entscheidet der Query Optimizer.

SQL Indices können im Gegensatz zu geschlüsselten logischen Dateien nicht in einem SQL-Statement angegeben werden.
Werden DDS beschriebene logische Dateien angegeben, löst der Optimizer die logischen Dateien auf, d.h. das SQL-Statement wird basierend auf den physischen Dateien mit der Feld-Auswahl, Join-Anweisungen und Select/Omit-Anweisungen (als Where-Bedingungen) neu geschrieben.
Erst im Anschluss ermittelt der Optimizer die optimalen Zugriff-Wege und zwar einen eigenen für jede verknüpfte physische Datei (Tabelle).

Die Auflösung der DDS-beschriebenen Dateien kann nur durch die alte (classic) Query Engine (CQE= erfolgen. Allein das Rerouting von der neuen SQL-Query-Engine (SQE) zur CQE kann bis zu 10% Performance-Einbußen mit sich bringen.

Abfragen die durch die SQE verarbeitet werden, sind z.T. wesentlich schneller als Abfragen, die durch die CQE verarbeitet werden.

Ausserdem wurden in den letzten Releasen Neuerungen in SQL eingeführt, z.B. EXCEPT, INTERSECT, OLAP-Ranking-Funktionen und rekusrive Abfragen, die NUR durch die SQE verarbeitet werden können.

Birgitta