Unterschiedliche Ergebnisse Heidi vs TFDQuery

[Ykcim]

Hallo Zusammen,
ich habe ein Phänomen, dass ich mir nicht erklären kann... Ich baue meine SQL-Statements mit HeidSQL zusammen und übertrage sie dann in meine Software. Das hat bislang auch immer gut geklappt.
Jetzt habe ich aber ein Statement, welches mir in HeidiSQL das richtige Ergebnis liefert, aber in meinem Programm ein anderes...

Hier das SQL-Statement:

Delphi-Quellcode:

procedure TMxSQL.Get_StockMovements(KDArtikelNr, BDArtikelNr: string; var LStream: TMemoryStream);
var   Logic: TLogic;
      MsQuery: TFDQuery;
      MsQryArtikelNr: TFDQuery;
begin
   Logic := TLogic.create;
   Logic.Set_Query(MsQuery, DB_Modul.MSConnect);
   Logic.Set_Query(MsQryArtikelNr, DB_Modul.MSConnect);
   Try
      if KDArtikelNr <> '' then begin
         MsQryArtikelNr.SQL.Add('select max(afg__ref) as afg__ref from afgart__ where zynrefkl = :KdArtikelNr');
         MsQryArtikelNr.ParamByName('KdArtikelNr').AsString:= KDArtikelNr;
         MsQryArtikelNr.Open;
         BDArtikelNr:= MsQryArtikelNr.FieldByName('afg__ref').AsString
      end;

      MsQuery.SQL.Add('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.ParamByName('BDArtikelID').AsString:= BDArtikelNr;
      MsQuery.Open;

      if Assigned(LStream) then begin
         LStream:= QryToStream(MsQuery);
      end;
   Finally
      MsQuery.Free;
      MsQryArtikelNr.Free;
      Logic.Free;
   End;
end;

Die beiden Ergebnisse und das HeidiSQL-Statement hänge ich als Bilder an. Bei Result_HeidiSQL bekomme ich richtiger Weise unterschiedliche Bewegungsdaten mit den unterschiedlichen Lagerorten. Bei Result_TFDQuery sind die Bewegungsdaten und Lagerorte identisch, nämlich wie die älteste Bewegung.

Die Tatsache, dass das Ergebnis unterschiedlich ist, verunsichert mich...

Kann mir jemand da etwas zu sagen?

Vielen Dank
Patrick

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

Zitat von Lemmy (Beitrag 1535671)

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]

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

[stifflersmom]

Zitat:

Zitat von haentschman (Beitrag 1535678)

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

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

[Ykcim]

Hallo Zusammen,

vielen Dank für Eure Antworten. Leider kann ich es ausschließen, dass es sich um unterschiedliche Datenbanken handelt. Die ist definitiv die selbe! Ich werde es mal mit einem anderen Query-Manager testen.
Könnt Ihr einen empfehlen?

Aber das löst das grundsätzliche Problem noch nicht, wie ich im meinem Programm die Daten so ausgegeben bekomme, wie sie benötigt werden (Result_Heidi).

Ich hänge mal ein Screenshot an, wie die Daten ohne Gruppierung vorliegen...

Vielen Dank
Patrick

[Ykcim]

Zitat:

Die Grid wird wahrscheinlich gesonderte Spaltenbezeichnungen haben und deshalb sind die Namen wohl unterschiedlich.

Das ist richtig. Das Grid wird für die Ausgabe angepasst. Das hat aber nur etwas mit dem Layout und den Spaltenüberschriften zu tun und hat keinen Einfluss auf die Daten!

Zitat:

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

In diesem Bereich werden Artikel, für Kunden an deren Kunden in vielen kleinen Teillieferungen über einen längeren Zeitraum versendet. Und da haben gibt es einen Lagerort mit schnellem Zugriff und Lagerorte für Vorrat. Daher liegt der Artikel auf mehreren Lägern...

[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? :gruebel:
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 :angle:

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.

Delphi-Quellcode:

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.

Delphi-Quellcode:

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

[stifflersmom]

Zitat:

Zitat von Ykcim (Beitrag 1535682)

Hallo Zusammen,

vielen Dank für Eure Antworten. Leider kann ich es ausschließen, dass es sich um unterschiedliche Datenbanken handelt. Die ist definitiv die selbe! Ich werde es mal mit einem anderen Query-Manager testen.
Könnt Ihr einen empfehlen?

Aber das löst das grundsätzliche Problem noch nicht, wie ich im meinem Programm die Daten so ausgegeben bekomme, wie sie benötigt werden (Result_Heidi).

Ich hänge mal ein Screenshot an, wie die Daten ohne Gruppierung vorliegen...

Vielen Dank
Patrick

Ich glaube kaum, dass es an Hedi liegt.
Führ die Abfrage doch mal einfach in der "shell" vom DB-Server aus, da kannst Du das Ergebnis ja auch betrachten.
Also einfach auf dem DB-Server mysql tippen und Enter drücken. Dann die Abfrage da feuern.
Wenn wirklich sicher gestellt ist, dass es derselbe Datenbankserver ist, dann käme natürlich noch eine "vergessene" Filterkonfiguration des Anzeige Grids in Frage.

[himitsu]

Zitat:

Zitat von Ykcim (Beitrag 1535687)

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:

Zitat von himitsu (Beitrag 1535685)

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

siehe #10 :stupid:

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

[Uwe Raabe]

Um ein grundsätzliches Problem bei FireDAC auszuschließen bzw. zu bestätigen, könntest du die Query direkt im SQL-Editor einer TFDQuery ausführen. Das entspricht im Wesentlichen dem was du mit HeidiSQL machst. Wenn das funktioniert, liegt dein Problem woanders.

[Ykcim]

Vielen Dank für die Unterstützung!
Ich bin sehr froh, dass mein Programm jetzt die gleichen Daten wie HeidiSQL anzeigt und der Fehler in meinem Programm zu finden war, weil ich mit der Heidi immer gerne zusammenarbeite... :wink:

Lieben Gruß
Patrick