Probleme mit mySQL Version 5.6.x: Unterschied zwischen den Versionen
(→Auswirkung) |
|||
| (4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt) | |||
| Zeile 1: | Zeile 1: | ||
| − | == Problem: mySQL Version 5.6 bringt fehlerhafte Daten zurück == | + | == Problem Variante 1: 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!''' | 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 einzige von GEVITAS freigegebene Treiber-Version ist 3.51.12!''' | ||
| + | |||
| + | |||
| + | == Problem Variante 2: mySQL Version 3.51.28 bringt fehlerhafte Memo-Daten zurück == | ||
| + | |||
| + | Diese mySQL-ODBC-Treiber-Version bringt fehlerhafte Daten in Meno-Feldern (RTF) zurück: | ||
| + | |||
| + | Statt der Texte werden nur endlose Ziffernfolgen angezeigt! | ||
| + | |||
| + | '''Wir raten von der Verwendung dieser Version von mySQL dringend ab!''' | ||
| + | |||
| + | |||
== Auswirkung == | == Auswirkung == | ||
| Zeile 9: | Zeile 22: | ||
* [http://stackoverflow.com/questions/16589296/mysql-not-generating-correct-results-using-odbc-date-parameter Forumseintrag in StackOverflow]. | * [http://stackoverflow.com/questions/16589296/mysql-not-generating-correct-results-using-odbc-date-parameter Forumseintrag in StackOverflow]. | ||
| − | 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 | + | 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 unregelmäß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! | ||
| − | [ | + | Vermutlich hängt das Problem mit einer neuen [http://dev.mysql.com/doc/refman/5.6/en/date-and-time-literals.html Behandlung des Datumsformats] ab, die mit Version 5.6.4 eingeführt wurde. Es ist also zu vermuten, dass der Fehler bei Versionen von 5.6.4 nicht auftritt. |
== Manchmal keine Daten == | == Manchmal keine Daten == | ||
Aktuelle Version vom 1. März 2017, 12:01 Uhr
Inhaltsverzeichnis
1 Problem Variante 1: 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!
Die einzige von GEVITAS freigegebene Treiber-Version ist 3.51.12!
2 Problem Variante 2: mySQL Version 3.51.28 bringt fehlerhafte Memo-Daten zurück
Diese mySQL-ODBC-Treiber-Version bringt fehlerhafte Daten in Meno-Feldern (RTF) zurück:
Statt der Texte werden nur endlose Ziffernfolgen angezeigt!
Wir raten von der Verwendung dieser Version von mySQL dringend ab!
3 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 unregelmäß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!
Vermutlich hängt das Problem mit einer neuen Behandlung des Datumsformats ab, die mit Version 5.6.4 eingeführt wurde. Es ist also zu vermuten, dass der Fehler bei Versionen von 5.6.4 nicht auftritt.
4 Manchmal keine Daten
Wenn manchmal keine Daten im Report stehen, kann diese Option in der ODBC-Einstellung u.U. Abhilfe schaffen:
