Probleme mit mySQL Version 5.6.x: Unterschied zwischen den Versionen
(→Auswirkung) |
(→Problem: mySQL Version 5.6 bringt fehlerhafte Daten zurück) |
||
Zeile 2: | Zeile 2: | ||
Die genannte mySQL-Version bringt in Verbindung mit CrystalReports u.U. fehlerhafte Daten zurück! Dieser Artikel beschreibt das Problem. '''Wir raten von der Verwendung dieser Version von mySQL dringend ab!''' | Die genannte mySQL-Version bringt in Verbindung mit CrystalReports u.U. fehlerhafte Daten zurück! Dieser Artikel beschreibt das Problem. '''Wir raten von der Verwendung dieser Version von mySQL dringend ab!''' | ||
+ | |||
+ | Vermutlich hängt das Problem mit einer neuen Behandlung des Datumsformats ab, die mit Version 5.6.4 eingeführt wurde. | ||
== Auswirkung == | == Auswirkung == |
Version vom 4. September 2013, 21:52 Uhr
Inhaltsverzeichnis
1 Problem: mySQL Version 5.6 bringt fehlerhafte Daten zurück
Die genannte mySQL-Version bringt in Verbindung mit CrystalReports u.U. fehlerhafte Daten zurück! Dieser Artikel beschreibt das Problem. Wir raten von der Verwendung dieser Version von mySQL dringend ab!
Vermutlich hängt das Problem mit einer neuen Behandlung des Datumsformats ab, die mit Version 5.6.4 eingeführt wurde.
2 Auswirkung
Reports, die Datumsabfragen verwenden, liefern u.U. fehlerhafte Daten zurück, manchmal auch keine. Das Problem konnte reproduziert werden und ist bei mySQL auch als Bug-Report aufgenommen worden. Siehe u.a.:
Im konkreten Fall ging es um einen Report, der Auftragsdaten in einem bestimmten Zeitraum abruft. In ungefähr (!) einem von fünf Fällen brachte der Report falsche Daten zurück. Die SQL-Abfrage, die von Crystal erzeugt wurde, wurde auch direkt auf dem mySQL-Server ausgeführt (mySQL-Workbench) und brachte auch dort die unrfegelmäßigen Fehler! Somit scheiden Fehlerquellen wie Crystal, ODBC, Treiber, Netzwerk o.ä. definitiv aus!
REFLEX ist davon übrigens nicht betroffen, weil es zur Abfrage von Datumsfeldern einen andere Syntax verwendet als CrystalReports!
3 Manchmal keine Daten
Wenn manchmal keine Daten im Report stehen, kann diese Option in der ODBC-Einstellung u.U. Abhilfe schaffen: