Editcode in SQL beschriebener Datei ?

[ILEMax]

Hallo AS400 Fan's
SQL Beschriebene Dateien sollen ja schnelle sein als DDS beschriebene.

Bevor ich mich auf den SQL Pfad begebe ..
Wie kann ich den einen Editcode oder ein Editword an die SQL-Table hängen.
mal brauch ich nullenunterdrückung, mal tausenderpunkt und mal ein minus-vorzeichen. geht das mit SQL ?

Max

[Fuerchau]

Gar nicht, da dies keine SQL-Funktion ist.
Diese Funktionen dienen ja auch nur für eine DSPF/PRTF wenn diese die PF als Reference angeben.
Ansonsten hat dies keine Auswirkung.

Mach einfach für DSPF's und PRTF's eine eigene DDS-Referenz-Datei.

[B.Hauser]

Hallo,

SQL beschriebene Tabellen sollen nicht nur schneller als DDS beschriebene Dateien sein, sondern sie sind es auch!
Der Grund liegt dafür, dass in DDS beschriebenen Dateien beim Lesen von Daten eine Prüfung der gepackten numerischen Werte erfolgt, während beim Schreiben keinerlei Datenvalidierung erfolgt. Bei SQL beschriebenen Dateien ist dies umgekehrt, d.h. beim Schreiben erfolgt die Prüfung, nicht jedoch beim Lesen.

Du kannst übrigens über den iSeries Navigator für jede DDS beschriebene physische Datei den zugehörigen SQL-Code generieren. Was SQL nicht konvertieren kann bzw. nicht unterstützt, z.B. Edit-Codes, Datums-Formate, Values wird als Kommentar im SQL-Code gekennzeichnet.

• iSeries Navigator öffnen
• Verbindung herstellen
• Datenbanken
• Schemas (notfalls durch Positionierung und Rechtsclick die gewünschte Bibliothek hinzufügen)
• Schema öffnen
• Tabellen/Tables öffnen
• auf gewüschter Datei positionieren
• Rechtsclick und Generate SQL/SQL Generieren

Birgitta

[ILEMax]

Hallo vielen Dank.
ich finde es allerdings schon etwas schwach von SQL.
Wie stellen sich den Zahlen im interaktiven SQL dar ? Endloswürste mit führenden Nullen. Oder Kundennr. mit Tausenderpunkt? kann man die Darstellung gar nicht beeinflussen?
sch...
Max

[Fuerchau]

Die Darstellung im STRSQL wird automatisch an Hand des Feldtyps und des Job-DECFMT ermittelt.
Ansonsten kennt SQL ja kein Userinterface und benötigt dies daher nicht.
Für die Darstellung bist du rein selbst verantwortlich (Anwendungs-Design).

Ich verstehe daher deine Bedenken überhaupt nicht.

[B.Hauser]

Hallo Max,

hast Du eigentlich je mit interaktivem SQL gearbeitet?

Die Edit Codes und Datums-Formate, die Du im DDS angeben kannst sind dazu gedacht, dass man auch mit Befehlen wie WRKF den Feldinhalt strukturiert lesen kann.
Die Formatierungen haben jedoch nichts damit zu tun, wie die Daten intern gespeichert werden. Deshalb haben diese Formatierungen auch nichts in der Feldbeschreibung zu suchen. (Außerdem ist das DDS und nicht SQL-spezifisch und auch nicht im SQL-Standard festgehalten)

Mit SQL kann man die Formatierungen über F13=Services und 1.Sitzungsattribute ändern angeben. (Im iSeries Navigator kann man dies über JDBC-Setup und Format erreichen.) Hier kann z.B. das Datums- und Zeit-Format und die zugehörigen Trennzeichen festgelegt werden. Ebenso kann das Dezimal-Trennzeichen (*COMMA, *PERIOD, *JOB) ausgewählt werden. Die Tausender-Trennzeichen werden abhängig vom Format bestimmt und angezeigt.

Damit ist man nicht von vornherein auf ein festes Format festgelegt, sondern kann die Ausgabe beliebig steuern. Der Ami kann in der gleichen Datei den Dezimal-Punkt sehen, während der Deutsche lieber das Komma verwendet.

Birgitta

[ILEMax]

Ob ich jemals mir SQL gearbeitet habe.
Du bist ja ne nette.

Das sollte jedoch egal sein.
Kunden fordern im SQL und / oder Query ihre Daten so zu sehen, wie sie es gewohnt sind. Kundennr.: 0123456 und Betrag 1.234.5,67-

Da ich, um diese Anforderung zu erfüllen, schon mehrfach schlampig erstellte Dateien mit EDTCDE nachrüsten mußte, muß ich mich darauf Einstellen das dieser Komfort zukünftig nicht mehr da ist.

also, auch wenn es wehtut, daß ich SQL zu nahe trete, ich halte es für ein Manko.
MAX

[Fuerchau]

Nochmal, das hat mit SQL aber auch rein gar nichts zu tun.
Dem Kunden wird man wohl kaum STRSQL zumuten sondern man schreibt eine Anwendung dafür.
Und diese ist nun mal zuständig für die Präsentation der Daten.
SQL ist ausschließlich für die Bearbeitung (und das komfortabel und schnell) von Daten zuständig.

Wie Birgitta schon sagte, jeder Kunde möchte das ggf. anders und deshalb solltest du SQL nicht ablehnen.

Wenn du native mit RPG/LE Daten liest werden dir die Daten auch in interne Felder bereitgestellt.
Für die Ausgabe verwendest du nun mal DSPF's oder PRTF's.
Spätestens bei Java und/oder ODBC-Zugriffen oder Internetdarstellungen ist sowieso Schluss mit den Editcodes.

Da gibts dann ganz andere Möglichkeiten.

Also: Ein Manko für SQL ist dies überhaupt nicht.
Sorge in deinen DSPF's/PRTF's einfach für korrekte Editcodes.

[camouflage]

Nochmal, das hat mit SQL aber auch rein gar nichts zu tun.
Dem Kunden wird man wohl kaum STRSQL zumuten sondern man schreibt eine Anwendung dafür.
Und diese ist nun mal zuständig für die Präsentation der Daten.
SQL ist ausschließlich für die Bearbeitung (und das komfortabel und schnell) von Daten zuständig.

Wie Birgitta schon sagte, jeder Kunde möchte das ggf. anders und deshalb solltest du SQL nicht ablehnen.

Wenn du native mit RPG/LE Daten liest werden dir die Daten auch in interne Felder bereitgestellt.
Für die Ausgabe verwendest du nun mal DSPF's oder PRTF's.
Spätestens bei Java und/oder ODBC-Zugriffen oder Internetdarstellungen ist sowieso Schluss mit den Editcodes.

Da gibts dann ganz andere Möglichkeiten.

Also: Ein Manko für SQL ist dies überhaupt nicht.
Sorge in deinen DSPF's/PRTF's einfach für korrekte Editcodes.

Dem ist nichts hinzuzufügen.

[BenderD]

Hallo,

Aussagen wie SQL beschriebene Dateien sind schneller als DDS beschriebene oder DDS beschriebene Dateien sind schneller als SQLbeschriebene sind typische Marketing Aussagen und beide falsch!!! it depends, es gibt solche und solche und hängt auch davon ab, wie ich die Dateien verarbeite und von der Hardware auch.
Meine Erfahrung kann man in folgende Aussagen vergröbern:
- Mix zwischen alter Welt (RLA und DDS) und neuer Welt (alles SQL) ist ungünstig
- neue Welt braucht mehr Computer Ressourcen
- alte Welt braucht mehr menschliche Ressourcen
- im kleinen (z.B.: einzelner read) ist alte Welt schneller
- im großen ist neue Welt im Schnitt schneller
- im Highend (multiprozessor + parallel Database Feature) ist neue Welt schneller

Zu dem Editcode ist schon viel gesagt, der bezieht sich auf PRTF und DSPF und das kann man ja mit einer einzigen Datei mit Ref Feldern weiter nutzen, auch wenn man Dateien mit SQL erstellt.
Was SQL angeht, da kann man das meiste mit SQL Mitteln ebenso machen und zwar in einem View Layer (z.B. Query Nutzer). Bei fast allen Frontends kann man die automatische Umsetzung der numerischen Felder steuern, dazu ist bereits genug gesagt. Die Kundennummer kriegt man mit digits(Kundennummer) im Alfa Format angezeigt, sprich ohne Tausenderpunkte und mit führenden Nullen. In solch einem View Layer kann man dann gleich noch (eigene) Functions einbinden, die Währungsaufbereitung und jeden erdenklichen Schnickschnack können.
Wenn man denn gerade mal an so einem View Layer ist, dann kann man da auch gleich alle Joins (korrekt) abbilden, die Benutzer ansonsten selber (manchmal auch korrekt) machen; damit ist auch das Problem weg, dass man über solche aufbereitete Felder nicht joinen sollte.

mfg

Dieter Bender

Hallo AS400 Fan's
SQL Beschriebene Dateien sollen ja schnelle sein als DDS beschriebene.

Bevor ich mich auf den SQL Pfad begebe ..
Wie kann ich den einen Editcode oder ein Editword an die SQL-Table hängen.
mal brauch ich nullenunterdrückung, mal tausenderpunkt und mal ein minus-vorzeichen. geht das mit SQL ?

Max

[B.Hauser]

Hallo,

Aussagen wie SQL beschriebene Dateien sind schneller als DDS beschriebene oder DDS beschriebene Dateien sind schneller als SQLbeschriebene sind typische Marketing Aussagen und beide falsch!!!

hier scheint es mal wieder jede Menge Zweifel und Spekulationen zu geben!

Nur soviel sei gesagt, es gibt architektonische Unterschiede zwischen DDS beschriebenen physischen Dateien und SQL-beschriebenen Tabellen, die bewirken, dass der Lese-Vorgang aus SQL beschriebenen Tabellen schneller ist, als das Lesen aus DDS beschriebenen Tabellen.

Wer's nicht glaubt, liest sich am besten mal den folgenden Artikel durch und probiert's anschließend aus!

Modernizing Database Access
The Madness Behind the Methods
By Dan Cruikshank

Birgitta

[BenderD]

Hallo,

hier geht es nicht um Zweifel oder Spekulationen, sondern um Fakten und deine Argumentation im vorherigen Posting widerlegt dein letztes Posting selber:

Der Grund liegt dafür, dass in DDS beschriebenen Dateien beim Lesen von Daten eine Prüfung der gepackten numerischen Werte erfolgt, während beim Schreiben keinerlei Datenvalidierung erfolgt. Bei SQL beschriebenen Dateien ist dies umgekehrt, d.h. beim Schreiben erfolgt die Prüfung, nicht jedoch beim Lesen.

was ja heißt, dass SQL beim schreiben im Nachteil ist - sprich: der Mix entscheidet.
ich erlaube mir noch zu ergänzen, dass vor dem lesen noch der Query Optimizer zuschlägt, dass Access Pathes berechnet werden, mal besser mal schlechter, sodass der von dir reklamierte Vorteil sich auch wieder verkrümeln könnte.

Eine der typischen Eigenschaften von Marketiers ist, dass sie technische Aussagen vergröbern und verzerren bis es ihnen in den Kram passt.

Dieter Bender,

der manchmal nicht versteht, wer sich wann welche Schuhe anzieht

Hallo,


hier scheint es mal wieder jede Menge Zweifel und Spekulationen zu geben!

Nur soviel sei gesagt, es gibt architektonische Unterschiede zwischen DDS beschriebenen physischen Dateien und SQL-beschriebenen Tabellen, die bewirken, dass der Lese-Vorgang aus SQL beschriebenen Tabellen schneller ist, als das Lesen aus DDS beschriebenen Tabellen.

Wer's nicht glaubt, liest sich am besten mal den folgenden Artikel durch und probiert's anschließend aus!

Modernizing Database Access
The Madness Behind the Methods
By Dan Cruikshank

Birgitta