Editcode in SQL beschriebener Datei ?

[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.