View Full Version : Editcode in SQL beschriebener Datei ?
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
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.
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
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
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.
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
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
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
23-01-07, 11:35
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.
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