Leerer Datensatz bei SQL Abfrage

[MrSpock]

Hallo Hansa,

Zitat:

Aber wahrscheinlich hast Du andere Gründe, es nicht so zu machen.

Ich will die Datenmenge direkt für QRReport nutzen. Ich habe mir jetzt so geholfen, dass ich PrintBand auf False setze, falls der Eintrag leer ist. Ich habe aber noch ein Band, das nur gedruckt werden soll, wenn die Anzahl der nicht leeren Datensätze größer als 1 ist. Also habe ich versucht den leeren datensatz zu löschen, geht aber nicht, weil die Datenmenge nicht editierbar ist. Also laufe ich durch die Query und zähle die nicht leeren Datensätze und nutze das Ergebnis als Entscheidungsgrundlage für PrintBand.
Funktioniert, ist aber nicht gerade elegant.

[Hansa]

Hallo MrSpock,

so ungefähr habe ich mir das gedacht. Ich habe sogar an die Qreports gedacht , da ich mit berechneteten Feldern auch Schwierigkeiten hatte. Hierzu müßte hier ein Thread vorhanden sein. Vielleicht sollten wir den wieder zum Leben erweckenn, also ich jedenfalls habe das ganze zurückgestellt, da ich nicht weiterkam. Werde das auch jetzt mal suchen, um zu sehen, wo ich damals stehenblieb. Ich glaube aber trotzdem nicht, daß solch eine verschachtelte SELECT-Konstruktion nötig ist.

Gruß
Hansa

[xbu58]

Hallo MrSpock

Ich bin mir nicht sicher, ob ich Dein Problem richtig verstanden habe. Wenn Du zwei Datensätze möchtes, das aber nur, wenn im betreffenden Netto-Feld ein Wert steht, dann denke ich, das ist ein klarer Fall für den Einsatz von Having. Im SQL-Server sieht das wie folgt aus:

Code:

SELECT SUM(Netto1) AS SumNetto,
       ST1 AS ST,
       SUM(MwST1) AS SummSteuer,
       SUM(Netto1)+SUM(MwSt1) AS Brutto
FROM RechListe
GROUP BY ST1
HAVING SUM(Netto1) > 0
UNION
SELECT SUM(Netto2) AS SumNetto,
       ST2 AS ST,
       SUM(MwST2) AS SummSteuer,
       SUM(Netto2)+SUM(MwSt2) AS Brutto
FROM RechListe
GROUP BY ST2
HAVING SUM(Netto2) > 0

Im Gegensatz zum Where wird bei Having die Gruppierung berücksichtigt. Es gibt aber noch eine andere Schreibweise von HAVING. Anstelle der SUM-Funktion muss die Alias-Variable angegeben werden. SQLAnywhere macht das zum Beispiel. In diesem Falle sieht das dann so aus: HAVING SumNetto > 0

Gruss
Xaver

[Hansa]

Das von Xaver klingt plausibel. Werde mir jetzt doch mal ein reines SQL-Buch kaufen.

@xbu58 : Wo steht denn sowas verständlich drin ? Was ich im Internet finde ist zu knapp gehalten. Habe meinen UB-Ausweis upgedatet, aber die haben nur uralten Schrott. 10 Jahre ist da noch fast das jüngste.

Aber das ganze mit SQL wird ja immer komplizierter. Ich habe deshalb mal meinen Ansatz weiterverfolgt. Das Problem aus dem anderen Thread kam anscheinend daher, daß das dataset nicht active auf true war. Übung macht den Meister. Jetzt geht das schon, wie es soll. Meine Methode müßte so schon funktionieren. Aber nun muß ich mich noch einmal von vorne in QR einarbeiten. Bei einer Expression mit einem Datensatz und einer Multiplikation geht es jedenfalls. Eventuelle Werte mit 0 dürften sich doch auch leicht ausblenden lassen.

Gruß
Hansa

[MrSpock]

Hallo xbu58,

vielen Dank, genau das war es!
Der leere Satz ist weg.

Muss ich mir einprägen: HAVING, HAVING, HAVING ....

Jetz hab ich's.

[xbu58]

Hallo MrSpock

Feudt mich, dass ich einem Moderator etwas zeigen konnte

Überigens gibts beim Union noch eine Tücke! Wenn Du zwei Datensäzte aus beiden Statements hast, die genau gleich sind, wird einer unterdrückt. Das kann manchmal erwünscht sein aber in Deinem Fall glaube ich nicht. Du kannst das unterdrücken, indem Du UNION ALL schreibst. Wenn das nicht geht, kannst Du immer noch eine Konstante in beiden Script einfügen, welche jedoch unterschiedlich ist.

Code:

SELECT Typ=1 
...
UNION
SELECT Typ=2
..

Hoffe das geht.

Gruss
Xaver

[Hansa]

Hi,

wußte doch, ich brauche ein gutes Buch für den Kram, das wird ja immer doller, aber ich nehme an demnächst auch an solchen Klippen zu landen. Aber was ist denn jetzt, was spricht dafür das da so kompliziert direkt mit SQL zu machen ? Es geht doch nur darum, zwei Zahlen zu ermitteln Man sollte den C/S-Traffic nicht übertreiben, das ist schon klar, aber solche verschachtelte Abfragen dienen doch wohl auch nicht der Performance, zumal zumindest in diesem Falle wohl sowieso alle gewünschten Zahlen bereit stehen.

Gruß
Hansa

[xbu58]

Hallo Hansa

Zu Deiner Frage wo das drin steht. Na wenn ich das Dir sage, kann ich mit meinem Wissen nicht mehr auftrumpfen .

Ok, Spass bei seite. Es gibt ein sehr gutes SQL-Lehrbuch, das ich vor Jahren einmal gekauft habe. Ich habe es aber leider momentan nicht zur Hand, werde morgen nachsehen und die Angaben posten. Aber wie das so ist, kann man das meiste nur mit Erfahrung erlernen. Was aber auch sehr gut ist, ist die Hilfe vom Microsoft SQL-Server und SQLAnywhere. Die beschreiben die einzelnen Befehle sehr gut. Hier ein Beispiel aus dem SQLServer-Help

Code:

SELECT
Ruft Zeilen aus der Datenbank ab und ermöglicht die Auswahl einer oder vieler Zeilen oder Spalten aus einer Tabelle oder aus zahlreichen Tabellen. Die vollständige Syntax der SELECT-Anweisung ist komplex, die Hauptklauseln können jedoch wie folgt zusammengefasst werden:

SELECT select_list 
[ INTO new_table ] 
FROM table_source 
[ WHERE search_condition ] 
[ GROUP BY group_by_expression ] 
[ HAVING search_condition ] 
[ ORDER BY order_expression [ ASC | DESC ] ] 

Der UNION-Operator kann zwischen Abfragen verwendet werden, um ihre Ergebnisse zu einem einzigen Resultset zu kombinieren.

Syntax
SELECT statement ::= 
    <query_expression> 
    [ ORDER BY { order_by_expression | column_position [ ASC | DESC ] } 
        [ ,...n ]    ] 
    [ COMPUTE 
        { { AVG | COUNT | MAX | MIN | SUM } ( expression ) } [ ,...n ] 
        [ BY expression [ ,...n ] ] 
    ] 
    [ FOR { BROWSE | XML { RAW | AUTO | EXPLICIT } 
            [ , XMLDATA ] 
            [ , ELEMENTS ]
            [ , BINARY BASE64 ]
        } 
] 
    [ OPTION ( < query_hint > [ ,...n ]) ] 

<query expression> ::= 
    { <query specification> | (<query expression>) } 
    [ UNION [ ALL ] < query specification | ( < query expression > ) [...n ] ] 

<query specification> ::= 
    SELECT [ ALL | DISTINCT ] 
        [ {TOP integer | TOP integer PERCENT} [ WITH TIES] ] 
        <select_list> 
    [ INTO new_table ] 
    [ FROM {<table_source>} [,...n] ] 
    [ WHERE <search_condition> ] 
    [ GROUP BY [ALL] group_by_expression [,...n] 
        [ WITH { CUBE | ROLLUP } ]
    ]
    [ HAVING <search_condition> ]

Da die SELECT-Anweisung relativ komplex ist, werden detaillierte Syntaxelemente und Argumente nach Klauseln zusammengefasst aufgeführt:

Wie Du siehst, wird sehr genau auf die einzelnen Optionen eingegangen. Und natürlich gibt es dazu noch jede Menge Links zu anderen Seite, welche einzelne Bereiche beschreiben.

Gruss
Xaver

[Hansa]

hehe, wenn Du weiter auftrumpfen willst, nur zu. Hab nichts dagegen, dann spare ich mir das Buch, Du hast die Arbeit und ich leg mich dann auf die --> Du hast ja schon gesagt, das solle ich machen.

[xbu58]

Hallo Hansa

Also wirklich, Du bringst mich noch zum Schreien. Ich kann ja gar nicht so schnell antworten, wie Du Fragen stellst. (bin nur ein lansamer Schweizer)

Als zu der Traffic. Grundsätzlich bin ich der Meinung, dass die Traffic auf den Server gehört. Dadurch kannst Du auch mit 500 MHz Workstation noch flott arbeiten. Besonders wichtig wird dies, wenn man von tausenden von Datensätzen spricht. Hier kann man mit inteligenten SQL-Scripts ohne weiteres Geschwindigkeitsvorteile von Faktor 3 bis 4 herausholen. Ich habe z.B. in einem Fall eine Tabelle, in der über 500'000 Datensäzte vorhanden sind. Wenn ich diese über Netz lade, um eine Jahresauswertung zu machen, kann ich gleich schlafen gehen. Wenn ich das jedoch vom Server erledigen lasse, dauerts max. 3 Min. Da siehst Du was es bringt.

Gruss
Xaver