SQL - Unterschied in STRSQL und SQLRPGLE

[muadeep]

wenn ich nachfolgende SQL Anweisung über "strsql" aufrufe,
dann erhalte ich folgende Ergebnisse

Umsatz
196.783,30
214.842,42
20.981,26

bau ich aber die Abfrage in ein SQLRPGLE ein, dann sind zwar die Ergebnisse gleich,
aber die Sortierung der Daten ist unterschiedlich !!!

Umsatz
196.783,30
20.981,26
214.842,42

Warum?

select sum(FKs) as Tagesumsatz                                                   
  from myLib.myFile                                                  
  where FKaa > 0 and (not (int(FKaa/100000) = 86 or               
                             int(FKaa/100000)=75)) and FK1=501    
  group by FKdd                                                     
  having FKdd between 1091201 and '1' concat substr(replace(char(current date, iso),'-' , '') , 3, 6) 

[BenderD]

... ohne order by überlässt man die Sortierung der Query engine, die je nach Zugriffsplan unterschiedlich liefern könnte.
In diesem Fall liegt es vermutlich an der unterschiedlichen Optimierung: STRSQL tendiert zur Optimierung für wenige Zeilen, embedded SQL entscheidet sich öfter zur Optimierung für alle Zeilen.
Wenn man das nicht haben will, brauchts einen order by.

D*B

PS: mit dem Wechsel von Sortierfolgen ist vermehrt nach Hardware oder Software Upgrade zu rechnen!!!

wenn ich nachfolgende SQL Anweisung über "strsql" aufrufe,
dann erhalte ich folgende Ergebnisse

Umsatz
196.783,30
214.842,42
20.981,26

bau ich aber die Abfrage in ein SQLRPGLE ein, dann sind zwar die Ergebnisse gleich,
aber die Sortierung der Daten ist unterschiedlich !!!

Umsatz
196.783,30
20.981,26
214.842,42

Warum?

select sum(FKs) as Tagesumsatz                                                   
  from myLib.myFile                                                  
  where FKaa > 0 and (not (int(FKaa/100000) = 86 or               
                             int(FKaa/100000)=75)) and FK1=501    
  group by FKdd                                                     
  having FKdd between 1091201 and '1' concat substr(replace(char(current date, iso),'-' , '') , 3, 6) 

[muadeep]

jede Summe steht für ein Datum

Umsatz
196.783,30 = 20091201
20.981,26 = 20091203
214.842,42 = 20091202


wie kann ich dann da nach Datum sortieren
(Datum kommt aus dem "having ...")

having FKdd between 1091201 and '1' concat substr(replace(char(current date, iso),'-' , '') , 3, 6) 

[BenderD]

... einfach das Datum mit in den Selct aufnehmen und danach sortieren.

D*B

jede Summe steht für ein Datum

Umsatz
196.783,30 = 20091201
20.981,26 = 20091203
214.842,42 = 20091202


wie kann ich dann da nach Datum sortieren
(Datum kommt aus dem "having ...")

having FKdd between 1091201 and '1' concat substr(replace(char(current date, iso),'-' , '') , 3, 6) 

[muadeep]

versteh ich nicht!

welches Datum denn?

ich hab doch nur einen Datumsbereich
( ... between ... and ...)

[Fuerchau]

Deine Abfrage funktioniert auch nicht auf jedem Release und wie willst du die Ergebnisse zuordnen?

select FKdd, sum(FKs) as Tagesumsatz
from myLib.myFile
where FKaa > 0 and (not (int(FKaa/100000) = 86 or
int(FKaa/100000)=75)) and FK1=501
group by FKdd
having FKdd between 1091201 and '1' concat substr(replace(char(current date, iso),'-' , '') , 3, 6)

order by FKdd

[B.Hauser]

... FKDD muss nicht zwingend in die Auflistung beim Select übernommen werden (ist schon seit Release V5R1 nicht mehr erforderlich). Die Angabe im Order By reicht.
Benötigt man eine bestimmte Reihenfolge des Ergebnisses, muss man IMMER einen Order By angeben. Ist die Reihenfolge dagegen egal, sollte man auf einen Order By verzichten.

Embedded SQL und STRSQL können bei dem gleichen Statement unterschieldliche Indices ververwenden. Es kann sogar vorkommen, dass in einem Fall Table Scan und im anderen Fall ein Index verwendet wird.

Der Grund herfür liegt im unterschiedlichen Optimierungsziel. Alle dynamischen SQL-Interfaces (zu denen auch STRSQL gehört) werden so optimiert, dass der erste Block der Daten so rasch wie möglich ausgegeben wird (Optimization Goal = *FIRSTIO). Statisches SQL wird dagegen so optimiert, dass das komplette Ergebnis so schnell wie möglich ausgegeben wird (Optimization Goal = *ALLIO).

Auf das Optimierungsziel kann man durch das Hinzufügen von OPTIMIZE FOR x ROWS am Ende des Select-Statements. Wird für x ein sehr kleiner Integer-Wert angegeben wird *FIRSTIO verwendet, wird dagegen eine sehr große Zahl angegeben oder ALL wird das Optimiuerungsziel *ALLIO verwendet.

Birgitta

[Fuerchau]

Ich habe da schon verschiedenes mit Optimize versucht, bin aber nie zum selben Ergebnis wie STRSQL gekommen.
Selbst "Optimize for 1 rows" brachte keine Veränderung der Performance oder Sortierung bei embedded SQL.
Woran das nun liegt, habe ich dann nicht weiter analysiert.

[andreaspr@aon.at]

man könnte probieren, beide einmal auszuführen (STRSQL und SQLRPGLE) und dann im plancache schaun obs 2 verschiedene zugriffspfad-einträge für den gleichen sql-befehl (in der ausgeführten Uhrzeit) gibt.