Wir benutzen für unsere Buchhaltung den GS Buchhalter von Sage. Den kann man mit diversen Datenbanksystem betreiben, unter anderem auch mit MySQL 5, was wir dankend angenommen haben, da bei uns der Betrieb mit SageDB nicht möglich war.
Jedes Jahr gibt es für den GS Buchhalter ein Update, so auch beim Jahreswechsel von 2010 nach 2011. Dieses einzuspielen wird vom Sage-Support nicht nur empfohlen, sondern regelrecht gefordert. Während das die Jahre zuvor problemlos funktioniert hat war das dieses Mal nicht so. Diverse Vorgänge liefen in einen Fehler, die Buchhaltung konnte schlicht und ergreifend nicht arbeiten. Der Anruf beim Sage-Support brachte nur die Erkenntnis, dass da ein Fehler in unserem Server für verantwortlich sein müsste, das Update selbst wäre fehlerfrei (guter Witz am Rande, aber mir war zu dem Zeitpunkt nicht nach Lachen).
Nachdem ich von der Buchhaltung eine SQL-Fehlermeldung bekommen habe war mir schnell klar, wo das Problem ist und es war auch genauso schnell klar, dass es durch das Update ausgelöst wurde:
Illegal mix of collations (latin1_german1_ci,IMPLICIT) and (latin1_swedish_ci,IMPLICIT) for operation ‘=’.
Da die komplette Datenbank und alle darin enthaltenen Tabellen vom Sage-Installer (bzw. vom Updater) angelegt wurden geht die falsche Kollation ganz klar zu Lasten von Sage.
Denn die Tabelle mand
hat als Kollation latin1_swedish_ci
, während alle darin enthaltenen Tabellen die Kollation latin1_german1_ci
haben. Naja, nicht ganz alle. Nach dem Update existierten drei Tabellen, die auch latin1_swedish_ci
als Kollation nutzten: sage_auf_ratenzahlung
, sage_fib_buchungstexte_termine
und sage_fib_buch_split
. Offensichtlich hat der Updater die Kollation dieses Mal nicht explizit angegeben und daher wird die Kollation der Datenbank benutzt. Joins, die sowohl alte Tabellen als auch diese drei mit abweichender Kollation umfassen, laufen zwangsläufig in einen Fehler.
Man kann das Problem lösen, indem man die Kollation der Tabellen händisch auf latin1_german1_ci
ändert, auch die Datenbank selbst sollte man ändern, denn der nächste Sage-Updater hat eventuell genau den gleichen Bug und legt wieder Tabellen ohne explizite Kollationsangabe an.
Und was schreibt der Sage-Support, explizit auf die Punkte angesprochen?
Bei dem von Ihnen benannten Sachverhalt handelt es sich nicht um einen Programmfehler.
Nein, natürlich nicht. Und die Erde ist eine Scheibe!
Sieben Jahre später, nix hat sich verändert 🙂 Hi Matthias.
Wir haben die letzte Woche bei einem Kunden einen Windows SBS portiert auf unseren Debian Server, so dass diese SBS Kiste endlich dem Tod geweiht ist. Die Windows-Kiste lief allerdings noch, weil Sage sich geweigert hat, irgendeine Hilfestellung zu geben dafür, das auf Linux zu portieren.
Alles handgemacht, schlampig entwickelt, Queries in der Datenbank sind teilweise lowercase, teilweise uppercase, was bei MS-SQL anscheinend egal ist, MySQL unter Windows anscheinend auch? Keine Ahnung. Jedenfalls hat’s beim Portieren geknallt, weil irgendein angelegter Tabellenname nicht gefunden wurde. weil wohl die Tabelle uppercase angelegt wurde und lowercase abgefragt.
Mit drei Handgriffen (wie z.B. “lower_case_table_names = 1”) und diversen anderen Kleinigkeiten lief es einwandfrei…
Sage Support bleibt dabei, dass das auf Linux gar nicht erst läuft. Erst wenn man behauptet, dass es das längst tut, wissen sie weiter…
Es ist unfassbar.
Ja, Tabellennamen auf Linux sind für MySQL case-sensitive, Feldnamen nicht, was an Linux liegt, da die Tabellen als Files im Dateisystem existieren und dieses case-sensitiv ist.
Ich bin immer wieder schockiert, wie Firmen, in dem Fall Sage, mit schlechter Software und schlechtem Support groß werden konnten. Und wie sie trotzdem all die Jahre mit dem Schrott überleben.
Wir sind nach einem Wechsel des Steuerbüros mittlerweile bei Datev. Aber da ist nichts besser. Die Unfähigkeit hat nur andere Namen und andere Farben.