![]() |
AW: MySQL versus MsSQL Syntax Group By
Erstmal nur zur Fehlereingrenzung:
Delphi-Quellcode:
Ändert sich was?
Query.Open;
Query.Last; Query.First; Nicht alle Datenbankkomponenten laden grundsätzlich alle Datensätze, sondern nur die ersten X. (z. B. Attribut FetchRow bei den Zeoskomponenten.) Was gibt Dir Query.RecordCount aus? |
AW: MySQL versus MsSQL Syntax Group By
Interessant!
Nach Query.open ist der RecordCount bei 50, nach Query.Last ist der RecordCount bei 229... Das wäre also gelöst. Vielen Dank! |
AW: MySQL versus MsSQL Syntax Group By
Dieses Open-Last ist nur 'ne Krücke, die bestenfalls als suboptimal zu bezeichnen ist.
Gibt es bei Deiner Datenbankkomponenten ein Attribut, über das man sowas wie FetchRow, FirstRows, MaxRows o. ä. konfigurieren kann? Das ist leider nicht bei allen Datenbankkomponenten einheitlich. Bei ADO heißt es MaxRows, bei Zeos FetchRow, andernorts auch mal LoadLimit. Schau bitte mal, ob Dir dashier weiterhilft: ![]() FetchOptions -> fmAll |
AW: MySQL versus MsSQL Syntax Group By
Wenn du alle Datensätze direkt nach dem Öffnen brauchst (z.B. wegen des SaveToStream), dann musst du bei der Query in FetchOptions das
![]() Ups: zu spät |
AW: MySQL versus MsSQL Syntax Group By
Ich nutze die TFDQuery Komponente. Ich habe diese Einstellungen versucht, aber leider keinen Erfolg gehabt:
Delphi-Quellcode:
Die EInstellung RowSetSize schein standardmäßig auf 50 zu stehen. Das würde ja passen...
Query.FetchOptions.AutoFetchAll;
Query.FetchOptions.RowsetSize:=-1; Ich dachte, der Wert -1 oder 0 würde ihn auf unendlich stellen, aber dann bekomme ich nur einen Datensatz. Ich habe den Wert jetzt auf 99999999 gestellt, damit sollte ich bei der Anwendung auf der sicheren Seite sein... VIelen Dank |
AW: MySQL versus MsSQL Syntax Group By
Versuch mal
Delphi-Quellcode:
vor dem Open.
Query.FetchOptions.Mode := afAll
|
AW: MySQL versus MsSQL Syntax Group By
Zitat:
Wenn Du Dir die mySQL Denkweise abgewöhnst, dann bist Du genau richtig. Diesen Mist gibt es nur bei mySQL und er funktioniert nicht zuverlässig. Unabhängig von MSSQL, selbst in mySQL würde ich alle Group By Abfragen auf "normal" umstellen, falls Du da noch Projekte laufen hast. Und die Datenbank so umkonfigurieren, dass sie diese schlampige Notation nicht mehr akzeptiert. Dann verhält sich mySQL wie richtige Datenbanken und versucht nicht schlau zu sein und falsch zu liegen. Das Schlimme ist ja, dass Du es ab ein paar Tausend Datensätzen nur mit einigem Aufwand nachvollziehen kannst, ob richtig oder falsch. Vergiß die alte Denkweise einfach, falls es schneller sein sollte- was kaum nachvollziehbar wäre-, lohnt sich das Risiko überhaupt nicht. |
AW: MySQL versus MsSQL Syntax Group By
Zitat:
Zitat:
Aber ich bin ja lernfähig :thumb: Vielen Dank! |
AW: MySQL versus MsSQL Syntax Group By
Zitat:
Es ist wirklich ein gut gemeinter Hinweis. Schau Dir ein x-beliebiges mySQL Forum an (Ich glaube bei Maria ist es analog, da weiß ich nicht, wann dieses Verhalten- also ab welcher Version- per Default umgestellt wurde auf "normal" bzw. richtig.) Es wimmelt von Group By Fragen. Und das wäre ja noch okay, wenn es um das reine Verständnis geht. Die Leute, die nicht fragen und die Fehler in ihrer Datenausgabe nicht bemerken, sind am Ende die Dummen. Es ist mir ein Rätsel, warum so ein Produkt existiert (und so verbreitet ist), das willkürlich falsche Daten ausgibt. Und nur so: Die Faustregel für eine korrekte Group By Syntax (die nebenbei schon immer auch bei mySQL funktioniert): > alle Spalten der Ausgabe müssen entweder gruppiert oder aggregiert werden, ist doch recht übersichtlich. |
AW: MySQL versus MsSQL Syntax Group By
Ja, es ist etwas unlogisch, dass wenn du ein JOIN-Kriterium ein PK ist und trotzdem man alle Felder aggregieren oder gruppieren muss. Aber es ist konsequent bzgl. der Regel dass jedes Feld aggregiert oder gruppiert ist.
Übrigens: - Bei MSSQL fasst man Bezeichner in eckigen Klammern ein oder notfalls in doppelten Anführungszeichen. Einfache Anführungszeichen sind für Strings. - IIF ist übersichtlicher als ein CASE-WHEN-Konstrukt mit zwei Situationen. - COALESCE mit zwei Parametern ist zwar dasselbe wie ISNULL, aber ISNULL ist leichter verständlich. /Edit: Und performanter. - Und bitte benutze Views, statt so viele Zeilen SQL im Quelltext zu haben. - Und zu QuotedStr kein Kommentar. Na ja gut, egal. Namen der Tabellen und Felder sind der Horror. Dachte erst Paradox, aber das kannte immerhin längere Feldnamen. Zitat:
|
Alle Zeitangaben in WEZ +1. Es ist jetzt 07:19 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz