Editcode in SQL beschriebener Datei ?

[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

[Sven Schneider]

Und wenn es nur um Reports geht, hast du mit :

- Query/400 (WRKQRY)
- QM/Query (STRQM)

alle Möglichkeiten der Formatierung, unabhängig was du in der DDS/DDL definiert hast.

Die erstellten Reports kannst du dann auch einem Anwender an die Hand, geben im Gegensatz zu STRSQL.

[Fuerchau]

Stimmt, WRKQRY/STRQM interessieren sich nämlich überhaupt nicht für diese Editcodes.

[Sven Schneider]

Stimmt, WRKQRY/STRQM interessieren sich nämlich überhaupt nicht für diese Editcodes.

Die Editcodes werden bei Query/400 schon als Vorgabe verwendet, ich kann sie aber nach belieben ändern.

QM/Query, da SQL basiert, benutzt die Vorgaben nicht.
Ich kann aber mit Berichtsformularen genau diese Formatierungen (pro Feld) hinzufügen.
Bedingt durch die andere Technik sind die Formatierungmöglichkeiten bei Query/400 und QM/Query leicht unterschiedlich, dürfte aber trotzdem die meisten Anwendungsfälle abdecken. (QM/Query unterstützt keine Editierschablonen, die Datumsformatierung ist auch etwas anders)

[Fuerchau]

QM/Query kann auch kein Vorzeichen rechts des Wertes, es erlaubt ausschließlich amerikanische Editierungen (ausser Dezimalkomma, das aus dem Jobwert kommt).

[alfredo]

Hallo!

Noch ein paar ketzerische Gedanken.

a) Wir haben vor ca. 2 Jahrenauf Grund von Aussagen eines gewissen P.L., mit SQL erstellte Dateien seien x mal performanter uns die Mühe gemacht, das zu checken und konnten keinen signifikanten Unterschied entdecken.

b) Für die Wartung/Dokumentation sind mir die DDS-Sourcen mit Kommentaren/Wartungshistorie ehrlichgesagt lieber.

c) Obwohl es immer geleugnet wird, habe ich gute Erfahrungen mit gezielter Verwendung von LF und SQL bei Joins gemacht.