Unterschiedliche Ergebnisse Heidi vs TFDQuery

[Lemmy]

Guten Morgen,

da die Queries auf den ersten Blick identisch sind, das Ergebnis aber unterschiedlich, nennt meine Glaskugel 2 mögliche Fehlerquellen:
1. unterschiedliche Datenbanken
2. unterschiedliche Abfragen.

bzgl. 2 meine ich: Im Grid wird halt nicht die Query angezeigt, die du hier zeigst.


Etwas das mich triggert, mit der Frage aber vermutlich nix zu tun hat: Warum ist der Parameter LStream mit einem var deklariert? Das ist hier nicht notwendig, da du den Stream nicht innerhalb der Methode erzeugst.

Grüße
Lemmy

[Jasocul]

Teste das SQL mit einem anderen Frontend als HeidiSQL.
HeidiSQL habe ich nur kurz genutzt, weil es mir manchmal falsche Ergebnisse geliefert hat.

[stifflersmom]

Zitat von Lemmy:

Guten Morgen,

da die Queries auf den ersten Blick identisch sind, das Ergebnis aber unterschiedlich, nennt meine Glaskugel 2 mögliche Fehlerquellen:
1. unterschiedliche Datenbanken
2. unterschiedliche Abfragen.

bzgl. 2 meine ich: Im Grid wird halt nicht die Query angezeigt, die du hier zeigst.


Etwas das mich triggert, mit der Frage aber vermutlich nix zu tun hat: Warum ist der Parameter LStream mit einem var deklariert? Das ist hier nicht notwendig, da du den Stream nicht innerhalb der Methode erzeugst.

Grüße
Lemmy

Die Grid wird wahrscheinlich gesonderte Spaltenbezeichnungen haben und deshalb sind die Namen wohl unterschiedlich.
Aber ich schließe mich in Deiner Vermutung der Möglichkeit 1 an.
Wahrscheinlich sind die Quellen unterschiedlich. Bei Heidi bist Du vielleicht im Testsystem unterwegs und bei den anderen Werten in Live-System?

[haentschman]

Der gleiche Artikel...verschiedene Lagerorte? (Bild 1)

[stifflersmom]

Zitat von haentschman:

Der gleiche Artikel...verschiedene Lagerorte? (Bild 1)

Warum nicht?
Bei uns gibt es auch Überbestandslagerorte, das muss also kein Fehler sein.

[himitsu]

Jo, oder "Masse" und ein Ort reicht nicht.
Wir haben es auch bei einigen Kunden, welche auch teilweise eigene Lagerorte für bestimmte Maschienen haben, oder auch mehrere Produktionshallen usw.
Ein Kunde hat auch ein extra Lager für einen seiner Kunden, der bei sich kein Lager hat.
...


nur das Bewegung und Lagerort falsch?

Nja Datum könnte sein, wenn MAX und GROUP in falscher Reihenfolge (MAX auf Alles oder nur die Gruppe).
Und der Lagerort, wenn vorm Gruppieren eine andere Reihenfolge, bzw. welcher der Datensätze beim GROUP dann genommen wird.

Aber das Query sollte doch in der DB (Datenbankserver) ausgeführt werden und demnach kann es doch eigentlich keinen Unterschied machen, welcher Client das Ergebnis abruft?
Ist ja nicht sowas wie SQLite, wo der Client die eigentlich Arbeit macht und die DB nur die Daten hält.

[himitsu]

Warum eigentlich ADD (hoffentlich wird irgendwamm mal ein CLEAR nicht vergessen) und nicht einfach TEXT?

PS: Delphi 12 und MultiLineStrings

Code:

      MsQuery.SQL.Text := '''
        SELECT
          h.afg__ref AS BD_ArtikelNr,
          a.zynrefkl AS Kd_ArtikelNr,
          a.afg_oms1 AS Bezeichnung,
          max(h.kla__ref) AS Kd_Nummer,
          max(h.kla__rpn) AS Kd_Name,
          max(h.datum___) AS Bewegung,
          h.vak__ref AS Lagerort
        FROM hisafg__ h
        LEFT JOIN afgart__ a ON a.afg__ref = h.afg__ref
        WHERE h.afg__ref = :BDArtikelID
        GROUP BY
          h.afg__ref,
          a.zynrefkl,
          a.afg_oms1,
          h.vak__ref
        ORDER BY MAX(h.datum___) DESC
      ''';

      MsQuery.SQL.Add('''
        SELECT
        ...
        ORDER BY MAX(h.datum___) DESC
      ''');

Implizite AS hasse ich irgendwie. Würde mir eher wünschen man könnte sowas deaktivieren.
Hier hatten wir mal ein Komma vergessen und uns gewundert, warum ein Feld den komplett falschen Inhalt hat ... klar, war ja der Inhalt des anderen Feldes.
FROM hisafg__ AS h

[Ykcim]

Hallo Zusammen,

das ist mir jetzt peinlich, aber der Fehler lag ganz woanders - und ich habe tagelang danach gesucht...
Mir hat der EInwand von Lemmy keine Ruhe gelassen und ich habe mir die Daten direkt an Ausführung der Query in einem Array anzeigen lassen - und siehe da, in dem waren sie korrekt.

Ich hatte Schwierigkeiten, dass die Daten nicht sauber über den Stream an den Client übertragen wurden und habe daher verschiedene Wege ausprobiert, die ich hier aber nicht gepostet hatte. Einer der Wege, führte die Query erneut aus (das hatte ich übersehen). Und da die Query vorher nicht geleert wurde (himitsu), kam Murgs dabei raus.

Logic.Set_Query(MsQuery, DB_Modul.MSConnect); Hier wird zwar sichergestellt, dass die Query leer ist, aber wenn man sie später erneut ausführt (völlig sinnfrei) hätte sie ebenfalls leergemacht werden müssen.

Vielen Dank, Eure Anregungen haben mir sehr geholfen!
Patrick

[himitsu]

Zitat von Ykcim:

Hier wird zwar sichergestellt, dass die Query leer ist, aber wenn man sie später erneut ausführt (völlig sinnfrei) hätte sie ebenfalls leergemacht werden müssen.

Zitat von himitsu:

Warum eigentlich ADD (hoffentlich wird irgendwamm mal ein CLEAR nicht vergessen) und nicht einfach TEXT?

siehe #10

[anse]

Edit: sorry, hat sich zeitlich überschnitten, hast ja die Lösung schon.

Wenn ich das richtig sehe liegen die Unterschiede in der Art welche Zeilen der Server bei GROUP BY liefert. Das könnte durchaus mit dem verwendeten Treiber zusammenhängen. In HeidiSQL verwende ich für MS SQL den Data.Win.ADODB.TAdoConnection mit folgendem ConnectionString:

Code:

Provider=MSOLEDBSQL;
Password="...";
Persist Security Info=True;
User ID=...;
Network Library=DBMSSOCN; <-- nur bei TCP/IP
Data Source=.\SQLExpress; <-- oder was auch immer als Host eingetragen wurde
Application Name=HeidiSQL;
DataTypeCompatibility=80; <-- siehe https://learn.microsoft.com/en-us/sql/connect/oledb/applications/using-ado-with-oledb-driver-for-sql-server?view=sql-server-2017

Du kannst das ja testweise auch mal mit der TAdoConnection probieren.