Ich verbrachte einen Tag oder so stochern, und glaube nicht, dass es ohne wesentliche Änderungen des Treibercodes oder eine extrem schwierig zu erstellen Build-Umgebung für alte Versionen möglich ist.
Ich gebe dies in eine Antwort, damit andere Leute nicht das gleiche Kaninchenloch fallen, das ich getan habe (oder, noch besser, so können andere Leute dort anfangen, wo ich aufgehört habe und das Problem tatsächlich beheben!). ..und es passte nicht in einen Kommentar.
Dies wird ein bisschen ein Wälzer, sorry.
Übersicht
ich in der Lage war jeder der Fehlerbedingungen zu reproduzieren, die Sie in Ihrem Beitrag erwähnt (Danke für eine gründliche und ausgezeichnete Frage!) Ein Paar von Ubuntu 16.04 Behälter verwenden, die MySQL 3.23 download von Oracle zur Verfügung, und alle von den Client-Bibliotheken, die Sie erwähnt haben, und ein paar anderen.
Unten finden Sie, was ich gefunden habe, während ich versucht habe, an jedem von Ihnen erwähnten Ort zusätzliche Lösungen zu finden, gefolgt von einigen "Next Steps" -Typ-Infos und einigen Proselyten über die Moral der Geschichte.
Alle diese Tests wurden mit den neuesten Versionen von Python 2, UnixODBC und pyodbc (über pip) für eine Lager Ubuntu 16.04 Docker Container ab 26.11.2017 durchgeführt.
Alle verwendeten URLs sind verlinkt, aber wenn Geschichte irgendein Anzeichen ist, können sie im Laufe der Zeit sterben, wenn man bedenkt, dass ein Großteil dieser Software fast zwei Jahrzehnte alt ist. Ich bin auch glücklich, irgendwelche/alle meine Shellscripts/Dockerfiles/modifizierte Treiberquellen zu veröffentlichen, wenn Sie möchten; nur ping mich in den Kommentaren.
old_password.so und MariaDB Connector/ODBC 3.0.2
Sie hatten Recht, dass dies die Fehlersuche Option mit dem größten Potenzial war. Hier ist, was ich getan habe:
Zuerst installierte ich die Connector/ODBC 3.0.2 Binärdatei und versuchte, über Python eine Verbindung herzustellen. Ich schlug den gleichen Fehler, den Sie meine ODBC für eine Datenquelle .ini Dateien haben nach der Konfiguration den Namen „Maria“, nämlich:
> pyodbc.connect('DRIVER={maria};Server=mysql;Database=mysql;User=admin;Password=admin')
pyodbc.Error: ('HY000', u'[HY000] [unixODBC][ma-3.0.2]Plugin old_password could not be loaded: lib/mariadb/plugin/old_password.so: cannot open shared object file: No such file or directory (2059) (SQLDriverConnect)')
Der ODBC-Code versucht, wenn sie mit einem MySQL-Server hat ein Authentifizierungsprotokoll alt genug ankündigt, zu geladen kompilierte Plugins für die Connector/C MariaDB driver gebaut. strace In der Ausgabe der ODBC-Verbindungsversuche wurde dies festgestellt.
old_password.so entpuppt sich als eine Komponente des Connector/C MariaDB-Treibers, ist aber keine Bibliothek, die in den binären Versionen dieses Treibers enthalten ist. Interessant.
Es stellt sich heraus, dass es eine Reihe von Plugin-Modulen gibt, die old_password mit der Quelle des Connector/C-Treibers enthalten. Ich lud die Connector/C 3.0.2 sources herunter und öffnete die Dokumentation, die Quellen und das System für diese "auth" -Typ-Plugins, die als .so Dateien verteilt wurden, um zu sehen, was ich finden konnte.
Ich habe festgestellt, dass verschiedene Komponenten des Connectors/C entweder als Plugins kompiliert werden können, die statisch in die Haupttreiberbibliothek eingebunden sind, oder als dynamische Bibliotheken selbst. Ich sage "statisch" in Anführungszeichen, weil der Build-Prozess für den C-Treiber sowohl eine statische (.a) als auch eine dynamische (.so) Version von mariadbclient erstellt, aber wenn ein bestimmtes Plugin im Build-System als statisch deklariert ist, ist der Code dieses Plugins Statisch in beiden mariadbclient Artefakten enthalten.
Die Quellen für die old_password.so-Datei befanden sich in einer einzelnen kleinen Quelldatei unter plugins/auth/old_password.c.
Es schien, dass es möglich wäre, das Build-System (CMake) zu ändern, um eine dynamische Bibliothek für das old_password Plugin zu erzeugen. In den Connector/C Quellen gibt es eine cmake/plugins.cmake Datei, die als "Registry" für alle Plugins fungiert.Es enthält ein Cmake-Makro REGISTER_PLUGIN, das ein STATIC oder DYNAMIC Argument dauert. Ich suchte in dieser Datei für old_password und fanden die folgende Zeile:
REGISTER_PLUGIN("AUTH_OLDPASSWORD" "${CC_SOURCE_DIR}/plugins/auth/old_password.c" "old_password_client_plugin" "STATIC" "" 0)
Das vielversprechend aussah. Modellierung aus ähnlicher Linien, die .so Dateien für ihre Plugin generieren tat, änderte ich diese Zeile der folgenden und lief den Build:
REGISTER_PLUGIN("AUTH_OLDPASSWORD" "${CC_SOURCE_DIR}/plugins/auth/old_password.c" "old_password_client_plugin" "DYNAMIC" "old_password" 1)
Der Build fehlgeschlagen ein paar Mal wegen fehlenden Abhängigkeiten. Ich musste ein paar -dev Pakete und andere Tools installieren, aber am Ende konnte ich sauber bauen (nur für die Plugins stellt es sich heraus, dass Sie weder CURL noch OpenSSL benötigen). Sicher genug, eine Datei mit dem Namen mysql_old_password.so wurde im Verzeichnis plugins/auth als Build-Artefakt erstellt. - Jetzt brauchte ich meinen Python-Code, um das Plugin zu finden; Es gab mir immer noch den Fehler, lib/mariadb/plugin/old_password.so nicht zu finden. Ich lieferte das PLUGIN_DIR Argument, das Sie in Ihrer Frage zu der ODBC-Verbindungszeichenfolge erwähnten, umwandelte meine kompilierte mysql_old_password.so zu old_password.so und führte den folgenden Code aus. . . und habe einen neuen Fehler bekommen! Fortschritt!
conn = pyodbc.connect('DRIVER={maria};Server=mysql;Database=mysql;User=admin;Password=admin;PLUGIN_DIR=/home/mysql/zclient/mdb-c/plugins/auth')
pyodbc.Error: ('HY000', u'[HY000] [unixODBC][ma-3.0.2]Plugin old_password could not be loaded: /home/mysql/zclient/mdb-c/plugins/auth/old_password.so: undefined symbol: ma_scramble_323 (2059) (SQLDriverConnect)')
Sieht aus wie das kompilierte Artefakt ist gebrochen, die ma_scramble_323 Funktionsdefinition fehlt. Da das Plugin zur Laufzeit dynamisch geladen wird, startet das Programm trotzdem, aber wenn es versucht, das Plugin dload zu kopieren, wird es explodieren. Schlimmer noch, diese Funktion sieht so aus, als sei sie der Haupteingangspunkt für den Password-Hashing für den "alten" MySQL-Protokollauthentifizierungsmechanismus, also konnte ich nicht einfach abbrechen. In den Connector/C-Quellen habe ich die Deklaration für diese Funktion und den Header gefunden (mariadb_com.h), aber include, die an verschiedenen Stellen in der old_password.c Quelldatei nicht den Anschein hatte. Meine Vermutung ist, dass dies die Interaktion zweier unglücklicher Verhaltensweisen ist. Zuerst werden die Plugins, die vom Connector/C-Build-System kompiliert wurden, so eingerichtet, dass sie nur durch das Connector/C-Plugin oder etwas Ähnliches verknüpft werden. Dies bedeutet, dass die Plugins selbst nicht mit der "üblichen" Connector/C-Funktionalität verknüpft sind, wenn sie kompiliert werden, da diese Dinge bereits in der Sache verfügbar sein sollten, die das Plugin lädt. Da wir Connector/ODBC und nicht Connector/C verwenden, sind diese allgemeinen Funktionen nicht vorhanden oder nicht verfügbar. Nun, Connector/ODBC aus der Quelle zu erstellen, benötigt Connector/C, so dass es vielleicht möglich ist, eine neue Connector/ODBC-Bibliothek so zu kompilieren, dass sie die richtigen Funktionen enthält, aber ich wollte dieses Kaninchenloch nicht starten. Zweitens, selbst wenn gesagt wurde, das old_password Plugin im Standalone-Modus (Kompilieren Sie nichts anderes) zu erstellen, hat die Abhängigkeitsanalyse von CMake die Dateien, die die ma_scramble_323 beschrieben haben, nicht gefunden oder verlinkt. Das könnte ein CMake-Problem sein, aber wahrscheinlich liegt es daran, dass das Build-System nicht mit diesem Anwendungsfall konfiguriert wurde, wie oben erwähnt.
Hier hatte ich sehr viel Glück. Die ma_scramble_323-Funktion ist in libmariadb/ma_password.c definiert, die eine sehr kleine, einfache Quelldatei ist, die keine signifikanten Abhängigkeiten zu anderen Bibliotheken im Connector/C-Projekt aufweist, auf die das Plug-in old_password noch nicht angewiesen war. Ich habe "die Verknüpfung des armen Mannes" (yuck) und kopierte gerade die Quellen der ma_scramble_323 Funktion in die old_password.c Akte. Diese Funktionen haben andere Funktionen in der ma_password.c Datei, also habe ich diese kopiert. Auch dies war nur einfach (oder eine Option überhaupt), da die ma_password.c Datei so einfach war. Wenn es selbst Abhängigkeiten gehabt hätte oder komplexer gewesen wäre, hätte ich anhalten, fallenlassen müssen und fortgeschrittene CMake-Fu lernen müssen, um das Problem "richtig" zu lösen. Ich bin mir absolut sicher, dass es einen besseren Weg dafür gibt.
(Neben) an diesem Punkt musste ich eine regelmäßige Ausführung von mysqladmin flush-hosts auf meinem DB-Server cron, da meine Tests so viele fehlgeschlagene Versuche verursachte, dass ich dies häufig tun musste. Es gibt wahrscheinlich auch einen besseren Weg, aber ich weiß es nicht und ich kenne Cron.
Mit den neu "inlined" Quellen, die mysql_old_password.so Bibliothek kompiliert, ich habe es umbenannt, und führte mein Testskript erneut. Diesmal bekam ich:
pyodbc.Error: ('HY000', u'[HY000] [unixODBC][ma-3.0.2]Plugin old_password could not be loaded: name mismatch (2059) (SQLDriverConnect)')
Ich dachte, das etwas mit der Tatsache zu tun hatte ich die Datei wurde die Umbenennung, so dass ODBC finden kann (es sucht nach old_password.so nicht mysql_old_password.so). Ich versuchte es mit der Schrotflinte. In der Build-Systemkonfiguration plugins/auth/CMakeLists.txt habe ich alle Instanzen von mysql_old_password durch old_password ersetzt und kompiliert. Kompilierung ist gelungen, aber es hat immer noch nicht funktioniert.
Es stellt sich heraus, dass die Plugin-Quellen selbst (old_password.c in diesem Fall) eine Struktur-Deklaration an der Spitze haben, die ihren Namen ankündigt, und dieser gab seinen Namen als mysql_old_password bekannt. Dies könnte ein bereits existierendes Problem sein (d. H. Das hat nie funktioniert), und ich fühlte mich ein bisschen chillig: Wenn Sie Code erstellen, der sich anfühlt, als hätte niemand ihn in einer bestimmten Konfiguration erstellt oder getestet, Ihre Chancen auf Erfolg sind nicht gut. Egal, ich habe das gleiche s/mysql_old_password/old_password/ auf der Quelldatei auch, und kompiliert. Diesmal erzeugte es ein Artefakt mit dem richtigen Namen old_password.so. Ich lief mein Testskript wieder und bekam:
conn = pyodbc.connect('DRIVER={maria};Server=mysql;Database=mysql;User=admin;Password=admin;PLUGIN_DIR=/home/mysql/zclient/mdb-c/plugins/auth')
pyodbc.Error: ('HY000', u"[HY000] [unixODBC][ma-3.0.2]Access denied for user: '[email protected]' (Using password: NO) (1045) (SQLDriverConnect)")
Das war seltsam. Ich hatte den Befehlszeilenclient mysql, der mit dem 3.23 Server kam, der (über Tarball, nicht im Systembibliothekspfad) auf meinem Kliententestkasten auch geliefert wurde, und er konnte mit diesen Bescheinigungen gut anschließen (ich konnte nicht mit isql weil testen Ich konnte es nicht richtig verwenden PLUGIN_DIR und konnte nicht herausfinden, wo es mich wollte, um die Plugins zu setzen, es war nicht im System /usr Verzeichnis, noch die relativen). Ich konnte keinen Weg finden. Ich hatte meinen MySQL-Server mit allen üblichen "Ultra-promiscuous, testing only" GRANT s, für localhost und %, für jede Datenbank, für die admin Benutzer und das gleichnamige Passwort eingerichtet. Ich konnte immer noch melden Sie sich an via mysql auf der Kommandozeile
gab ich auf und das Passwort festgelegt/null zu leeren, Kennwort Auth deaktivieren, sicher zu machen, und zu versuchen, ein letztes Mal:
pyodbc.Error: ('HY000', u'[HY000] [unixODBC][ma-3.0.2]Error in server handshake (2012) (SQLDriverConnect)')
Dies erwies sich sei die Totenglocke. Bei der Untersuchung dieses Fehlers fand ich this GitHub issue, in der Leute ziemlich überzeugt zu sein schienen, dass dies eine fundamentale Client/Server-Protokoll-Inkompatibilität darstellte. An dieser Stelle gab ich den old_password.so Ansatz auf. Es scheint, dass die 3.0.2-Version des MariaDB-Treibercodes (C oder ODBC) keinen ausreichend alten Dialekt des MySQL-Protokolls zum Funktionieren spricht, obwohl es wahrscheinlich eine Menge möglicher Korrekturen gibt, die ich in diesem Prozess verpasst habe.
Andere Wege versucht
ich ein paar andere Dinge versucht, Sie in Ihrer Frage erwähnt, die ich kurz hier gehen werde:
Wie Sie wahrscheinlich gefunden, versuchen SQL_AUTO_IS_NULL Verhalten in der deaktivieren MariaDB 2.0 ODBC-Treiberfamilie funktioniert nicht gut.This bug thread und die ODBC Connector parameters list haben ein paar Vorschläge, wie die Einstellung dieses Feldes zu deaktivieren (Option=8388608 ist offensichtlich und klar, oder?), Aber keiner dieser Versuche, die Flagge gewaltsam zu deaktivieren oder zu aktivieren änderte das Verhalten, ob sie in der waren Verbindungszeichenfolge oder die ODBC .ini Dateien.
Die MySQL archive site hat alte Versionen des ODBC-Connectors verfügbar. Leider sind alle ihre kompilierten Versionen für 32-Bit-Linux, die ich nicht habe. Ich habe versucht, aus der Quelle zu bauen, und es war eine große Aufgabe, sogar die Toolchain zu konfigurieren. An dem Punkt wo ich musste hand-install system identification files from 1999 Ich wusste, es war wahrscheinlich eine verlorene Sache, aber ich habe alle Deps und alten Versionen installiert und versuchte es zu kompilieren. Die schiere Anzahl und Vielfalt der Kompilierungsfehler hat mich dazu veranlasst, diesen Ansatz aufzugeben (C-Standard-Fehlanpassungen und eine fehlende Kompatibilität mit dem, was fast jeder Teil von UnixODBC zu sein schien). Es ist absolut möglich, dass es zu diesen Problemen einfache Korrekturen gibt, die ich übersehen habe. Ich bin kein C-Coder oder Old-Linux-Build-System-Experte.
Ich versuchte einige third party MySQL ODBC connectors, die nicht funktioniert haben; gleiche Fehler wie bei der 5. * Familie.
Ich kompilierte die Version 2.50.39 der Connector/ODBC-Bibliothek (nur die Quellen waren im Archiv verfügbar). Um das zu tun, kompilierte ich zuerst die libmysqlclient.so.10 Dateien für die Version 3.23 des Servers. Dies erforderte die Quellen des 3.23-Server zu verändern einige errno damit verbundenen Probleme (entfernen Sie die #define Klausel für extern int errno in my_sys.h), das Kopieren der libtool OS Definitionsdateien an verschiedene Orte im Quellverzeichnis zu lösen (/usr/share/libtool/build-aux/config.{guess,sub} zum ., mit-pthreads kopiert wurde, und mit-pthreads/config/, wenn es darauf ankommt). Danach konnte ich die libmysqlclient Bibliotheken mit den --with-mit-threads --without-server --without-docs --without-bench Konfigurations-Switches kompilieren und erstellen. Die Kompilierung ist bei der Auswertung der Makros für das Client-Programm mysql mit mehreren unergründlichen Fehlern fehlgeschlagen, aber die .so Dateien für libmysqlclient wurden bereits erzeugt, also habe ich sie gepackt und bin weitergegangen. Nachdem die libmysqlclient.so.10 Bibliothek kompiliert wurde, baute ich die 2.50.39 version of Connector/ODBC from the archive. Das erforderte die Änderung einiger Quellen aus den Haupt-MySQL-Include-Dateien (Entfernen von Verweisen auf asm/atomic.h) und die gleiche Systemidentifikation libtool hacken wie die anderen Bibliotheken. Es konnte die iodbc libs (installiert auf Ubuntu über das libiodbc2-dev Paket) nicht finden, da sie jetzt in /usr/include statt /usr/local/include sind. Ich habe es schließlich mit den Schaltern --with-mysql-includes=$path_to_3.23_mysql_binary_dir/include --with-mysql-libs=$path_to_compiled_libmysqlclient.so.10_files_from_mysql_server_3.23_sources --with-iodbc-includes=/usr/include/iodbc konfiguriert, und es baute ohne Probleme andere als die oben genannten atomic.h Problem. Nach alldem verursachte die Verbindung über meine neu kompilierte libmyodbc.so einen Segfault in Python/UnixODBC. Valgrind, gdb und andere Tools waren nicht nützlich, um zu bestimmen, warum; Vielleicht könnte jemand, der sich mit dem Debugging kompilierter Bibliotheks-Interoperabilitätsprobleme besser auskennt, dieses Problem lösen.
Das MySQL-Archiv hat alte, binäre RPM-Versionen des Connectors/ODBC. Sie sind alle 32-Bit und fast alle modernen Linux-Systeme sind 64-Bit. Ich versuchte shimming diese Dateien durch die Installation der i386 Architektur und erforderlichen Bibliotheken. Das 64-Bit-Python/UnixODBC konnte die myodbc-Plug-Ins nicht erfolgreich laden, wodurch der generische Fehler "Datei nicht gefunden" zurückgegeben wurde, den ich letztendlich auf einen fehlgeschlagenen Aufruf von dlopen zurückführte. Libtools dlopen Wrapper (von UnixODBC verwendet) werden von den meisten Leuten als nicht sehr debuggbar angesehen, und nach einem erheblichen Aufwand schienen meine rudimentären Valgrind-Tricks, wie erwartet, zu zeigen, dass es nicht möglich war, eine Architektur inkompatibel zu laden (i386 vs x86-64) ODBC-Backend.
Solutions/Rest Optionen
Im Allgemeinen ist es wahrscheinlich sein wird einfacher, den Code auf Ihrer Seite neu zu schreiben. Zum Beispiel könnten Sie ein Python-Modul erstellen, das einen Legacy-Python-ODBC-MySQL-Treiber umschließt (wie @FlipperPA in den Kommentaren zu der Frage vorgeschlagen hat), "genug" von der pyodbc-Schnittstelle auf das Modul hacken, das Sie nicht benötigen Refactor zu viel von Ihrem Code, der es aufruft, und gründlich vor der Bereitstellung testen. Ich weiß, dass das scheiße ist und riskant ist, aber es ist wahrscheinlich deine beste Wette. Wenn Sie ein solches Modul schreiben, können Sie möglicherweise einen Teil des internen Codes in pyodbc verwenden, der die generische ODBC-Syntax/etc. Verarbeitet.
Sie sogar einen „fake“ ODBC-Backend für pyodbc, die gerade genannt nicht-ODBC Python MySQL-Treiber entwickeln könnten, aber ich vermute, dass schwierig sein würde, da pyodbc ‚s Back-End-Steckbarkeit in erster Linie eher auf kompilierten Bibliotheken ausgerichtet scheint als "Dummy" Shim-Code.
Ich bin kein Experte in diesem Zeug, also könnte es Lösungen geben, die ich verpasst habe!
Es gibt ein paar andere Möglichkeiten, die ich in Betracht gezogen und gab an:
Sie könnten einen Fehler mit dem MariaDB Leute-Datei und es könnte festgelegt werden. Ich habe kein gutes Gespür dafür, ob der Protokollfehler, mit dem ich endete, "das ist grundsätzlich auf jeder Ebene inkompatibel" oder "das Authentifizierungssystem braucht nur eine Feinabstimmung, dann wird alles funktionieren". Es könnte einen Versuch wert sein.
Da 32-Bit-RPMs des Connector/ODBC-Codes der Version 2.50 verfügbar sind (sie werden nicht in eine 64-Bit-Umgebung von Python/UnixODBC geladen), könnten Sie Ihren gesamten Stack (oder sogar die Betriebssystemverteilung) konvertieren) zu 32-Bit-Code. Wenn Sie jedoch nicht-allgemeines kompiliertes Material verwenden, wäre dies wahrscheinlich ein erheblicher Aufwand. Während Ubuntu/Debian besonders gut darin ist, Pakete auf alten Architekturen zur Verfügung zu stellen, könnte dies immer noch schwierig sein. Selbst wenn Sie alles konvertiert haben, können sich einige Verhaltensweisen ändern, und die alten 32-Bit-Eigenschaften wären für jeden, der an Ihrer App arbeitet, ein fortwährender Fremdkörper. Und das ist nur, wenn der Treiber 2.50 funktioniert, wenn von einer 32-Bit-Laufzeit zugegriffen wird; Es könnte andere Probleme geben, die danach auftauchen. Ich würde das nur empfehlen, wenn der Wartungsaufwand für Ihren gesamten Client-Code in Zukunft wahrscheinlich sehr niedrig ist (wenn das Projekt klein ist oder sich kaum ändern wird).
Moral der Geschichte
Software verrottet blutig schnell. Wenn sich ein Projekt nicht ständig dazu verpflichtet, rückwärtskompatibel zu arbeiten, werden die Dinge schnell zu Ende gehen, insbesondere in der Web-Software.
Es ist nicht so, dass das Produkt selbst zerbricht, es ist, dass das Universum sich auf Millionen von Wegen davon abwendet. Wenn jemand nicht genug von einem Generalisten ist und lange genug dabei ist, all diese kleinen Änderungen zu kennen und wie man sie umkehrt, ist es sehr schwer, alles in der Zeit/Revisionen zurück zu einem Ort zu bewegen, wo Dinge "einfach funktionieren".
Wenn Sie Binärdateien für etwas erhalten, auch wenn es etwas ist, das angeblich "üblich" ist, wie ein MySQL-Treiber, behalten Sie sie bei um. Idealerweise teilen Sie sie mit dem Internet.
Wenn Sie Quellen für etwas haben, dokumentieren Sie die gesamte Liste der Abhängigkeiten/Toolchain, die sie benötigen, rigoros und dokumentieren Sie sie als für Menschen.Angenommen, die zum Lesen von programmatischen Abhängigkeitslisten für z.B. Autotools werden selbst obsolet. Nichts ist zu "offensichtlich" zu dokumentieren; nicht Architektur, Kernel ABI, libc Verhalten - nichts. Nun, da wir Dinge wie Docker in einer Box in einem Kernel haben, können Sie möglicherweise mehr Ihrer Abhängigkeiten programmatisch speichern, aber zählen Sie nicht darauf.
In Xubuntu 16.04 konnte ich pyodbc 4.0.21 und MySQL Connector/ODBC 3.51.30 mit einem MySQL 4.0.26-Server arbeiten (was vor der Änderung der Authentifizierung in MySQL 4.1) also was Sie versuchen möglicherweise nicht * unmöglich *, aber MySQL 3.23 ist fast siebzehn (17) Jahre alt, also nicht "wette die Farm" darauf. –
Es könnte weniger Arbeit sein, einen 'mysqldump' aus der 3.23-Installation auszuführen und ihn in einer modernen Version von MySQL wiederherzustellen und dann eine Verbindung herzustellen. Außerdem erhalten Sie den Bonus, über ein Jahrzehnt Sicherheitslücken zu entfernen! – FlipperPA
@FlipperPA Danke euch beiden. Leider habe ich keine Möglichkeit, MySQL 3.23 zu aktualisieren, da es Teil eines Produkts ist, das mein Kunde verwendet. Ich habe meine Tests mit mariaDB-Treibern fortgesetzt. Das sieht ein bisschen vielversprechender aus, aber noch kein Erfolg. – jhinghaus