Seite 1 von 1
MySQL 5.5 Prove of Concept
Verfasst: Do 24. Nov 2016, 15:42
von Richman
Die gute Nachricht vorweg, seit einer Woche arbeite ich mit CAO unter MySQL 5.5 und das System verhält sich unauffällig.
Installiert ist alles lokal unter Windows 10 64Bit. Ich nutze nur die Module Einkauf, Verkauf, Stammdaten und Export.
Bei mir war ein Wechsel auf MySql 5.5 nötig, weil ich mit einem Laravel Programm auf die Datenbank von CAO zugreifen will und Laravel kann nicht mit MySQL 4.1.
Der Patch ist nur mit hartcodierten Ersetzungen ohne Fehlerroutinen programmiert und obwohl er bei mir funktioniert so nicht für die Allgemeinheit geeignet.
Er zeigt aber das es nur Kleinigkeiten sind die Zusammenarbeit von CAO und Mysql 5.5 verhindern.
Nachfolgend mein Installationsprotokoll:
Was macht der Patch:
1) Wir lügen wenn CAO nach Datenbankversion fragt
2) Wenn Mysql 5.5 den Datentyp NewDecimal zurückgibt wandeln wir den in Decimal, weil Mysql 3.23 kein NewDecimal kennt,
3) Bei einigen berechneten Feldern ändern wir den Datentyp explicit auf das was CAO erwartet
4) Beim Vorgang EK Bestellung ändern wir in der SQL abfrage ein Komma durch ein Join.
Im MySQL 3.23.49 Sourcecode die drei Dateien aus libmysql.zip austauschen und mit Visualstudio 2005 libmysql.dll erzeugen.
Das ich die 3.23.49 angepasst habe und nicht die 3.23.58 war Zufall
Datenbank Konvertierung
Backup der alten 4.1 Datenbank über Backupfunktion von CAO-Faktura
Import in 5.5 funktioniert nicht über CAO-Admin
Backupfile entzippen und im sql file folgende ersetzungen vornehmen (z.B. mit notepad++)
Type=MyISAM durch Engine=MyISAM ersetzen
'CURRENT_TIMESTAMP' durch CURRENT_TIMESTAMP ersetzen
VALUTA date default '0000-00-00' not null, durch VALUTA date default '0000-00-00', ersetzen
invdate date default '0000-00-00' not null, durch invdate date default '0000-00-00', ersetzen
In Table Export (Sonst Fehler bei öffnen des Export Moduls)
INFO text not null, durch INFO text,
QUERY text not null, durch QUERY text,
Installation MySQL 5.5.48 64 Bit Binary Version (5.6 funktioniert nicht)
Datenbank cao55 und User anlegen mit old pasword wie bei 4.1
Änderungen My.ini
default-storage-engine=INNODB ersetzen durch default-storage-engine=MYISAM
#skip-innodb ersetzen durch skip-innodb
query_cache_size=0 ersetzen durch query_cache_size=1M
Daten einlesen mit
mysql --show-warnings --user=MyUsername --password=MyPassword
use cao55
tee import.log
SOURCE c:\Server\MySQL55\bin\cao55.sql
Einlesen: Keine Warnungen mehr ausser Calc_Faktor out of range
Getestet mit CAO 1.4.3.4
Edit Admin: Download entfernt, kann gegen Lizenzrechte verstoßen
Re: MySQL 5.5 Prove of Concept
Verfasst: Do 24. Nov 2016, 16:33
von redone
Wenn es den so einfach wäre gäbe es schon die 1.5
Aber schön wenn es bei dir so läuft, was nicht heißt, dass es bei anderen auch funktioniert.
Wenn CAO mit der Datenbankkomponente läuft, die auch MySQL 5 unterstützt, reichen deine Änderungen nicht mehr.
Re: MySQL 5.5 Prove of Concept
Verfasst: Sa 26. Nov 2016, 08:25
von Sebastian.Herbig
Ich selbst finde solche Spielchen immer sehr interessant.
Daraus können sich oftmals neue Gedanken ergeben.
Allerdings ist das wirklich nichts für die Masse.
Ich finde gut, dass der Thread bleibt... dass der Download rausgenommen wurde verstehe ich, das wäre mir als Forenbetreiber auch zu riskant.
Weiter viel Erfolg.
Re: MySQL 5.5 Prove of Concept
Verfasst: Sa 26. Nov 2016, 10:20
von Richman
Um lizenzrechtliche Probleme zu umgehen der Auszug der von mir geschriebenen Codezeilen.
Code: Alles auswählen
+ //CAO-Start
+ //General Conversion Fieldtype NewDecimal
+ if (field->type == (enum enum_field_types) (uchar) 246)
+ {
+ //Return Decimal
+ field->type = (enum enum_field_types) (uchar) 0;
+ }
+ //Vorgang Mahnung
+ if (strcmp(field->name,"NEW_MAHNSTUFE") == 0)
+ {
+ //Return LongLong
+ field->type = (enum enum_field_types) (uchar) 8;
+ }
+ //Journal Lieferschein
+ if (strcmp(field->name,"POS_ANZ") == 0)
+ {
+ //Return Double
+ field->type = (enum enum_field_types) (uchar) 5;
+ }
+ //Journal Rechnung
+ if (strcmp(field->name,"MS") == 0)
+ {
+ //Return LongLong
+ field->type = (enum enum_field_types) (uchar) 8;
+ }
+ //Finanzen Zahlungseingang und Ausgang
+ if (strcmp(field->name,"ANZAHL") == 0 && field->type == (enum enum_field_types) (uchar) 8)
+ {
+ //Return Double
+ field->type = (enum enum_field_types) (uchar) 5;
+ }
+ //Finanzen Zahlungseingang und Ausgang
+ if (strcmp(field->name,"UEBERFAELLIG") == 0)
+ {
+ //Return LongLong
+ field->type = (enum enum_field_types) (uchar) 8;
+ }
+ //CAO-End
+
+ //CAO-Start
+ uint org_length = (uint) strlen(query);
+
+ //Vorgang EK-Bestellung
+ //Ersetze ARTIKEL, ARTIKEL_PREIS durch ARTIKEL Join ARTIKEL_PREIS
+ if (org_length > 943)
+ {
+ uint comma_pos = 376;
+ //Laenge ist abhaengig von Lieferanten Id ab
+ if (query[comma_pos] == ',' && org_length < 963)
+ {
+ char *hacked_query = (char*)malloc(1000);
+ const char *join = " JOIN";
+ memcpy(hacked_query,query,comma_pos);
+ hacked_query[comma_pos]='\0';
+ strcat(hacked_query, join);
+ strcat(hacked_query, query + comma_pos + 1);
+ return mysql_real_query(mysql,hacked_query, (uint) strlen(hacked_query));
+ }
+ }
+ return mysql_real_query(mysql,query, org_length);
+ //CAO-End
}
+ //CAO-Start
+ //Frag nicht den Server, sondern antwortet immer mit 4.1.22
+ return (char*) "4.1.22";
+ //CAO-End
}
Re: MySQL 5.5 Prove of Concept
Verfasst: Sa 26. Nov 2016, 12:45
von michael
Hi, gehe ich eigentlich Recht der Annahme, dass diese MySQL-Lizenz-Dingens mit MariaDB längst überholt ist?
Hier gibt es diese Lizenz-Probleme nicht mehr und wenn der CAO-Entwickler befürchtet, dass eine aktuelle Version nicht mit 4.1 kann, dann führt man eben den DB-Server in der Config mit
Dann gibt es überhaupt keine Probleme mit älteren SQLs. Es gibt keinen Grund mehr auf MySQL 4.x zu beharren. Alleine der Vorteil von Galera-Cluster ...
Gruß Michael
Re: MySQL 5.5 Prove of Concept
Verfasst: Sa 26. Nov 2016, 12:53
von michael
michael hat geschrieben:Hi, gehe ich eigentlich Recht der Annahme, dass diese MySQL-Lizenz-Dingens mit MariaDB längst überholt ist?
Hier gibt es diese Lizenz-Probleme nicht mehr und wenn der CAO-Entwickler befürchtet, dass eine aktuelle Version nicht mit 4.1 kann, dann führt man eben den DB-Server in der Config mit
Dann gibt es überhaupt keine Probleme mit älteren SQLs. Es gibt keinen Grund mehr auf MySQL 4.x zu beharren. Alleine der Vorteil von Galera-Cluster ...
Gruß Michael
Ach und falls ich irgendwie helfen kann, um solch einen Machbarkeitstest durchzuführen, einfach anschreiben. Erfahrung mit Umstellung auf MariaDB und Galera-Cluster habe ich reichlich vorzuweisen.
Re: MySQL 5.5 Prove of Concept
Verfasst: So 27. Nov 2016, 07:18
von hh-cm
michael hat geschrieben:Es gibt keinen Grund mehr auf MySQL 4.x zu beharren.
Wer sagt denn das wir auf Mysql 4.x beharren?
Re: MySQL 5.5 Prove of Concept
Verfasst: So 27. Nov 2016, 11:15
von michael
ok - falsch ausgedrückt: nicht ihr von der Entwicklung, sondern die Lizenz ist damit gemeint
Re: MySQL 5.5 Prove of Concept
Verfasst: Mo 28. Nov 2016, 07:10
von hh-cm
Da scheiden sich die Geister.
Sobald die Client libraries zum Verbinden genutzt werden, gilt die gleiche Lizenz wie bei Mysql. Da Mariadb ein Fork von Mysql ist.
CAO 1.4 nutzt nunmal diese libraries. Die 1.5 wiederum benötigt diese nicht.
Re: MySQL 5.5 Prove of Concept
Verfasst: Mo 7. Aug 2017, 09:18
von N. Lange
hh-cm hat geschrieben:Sobald die Client libraries zum Verbinden genutzt werden, gilt die gleiche Lizenz wie bei Mysql. Da Mariadb ein Fork von Mysql ist.
Unabhängig von V1.5 (und UniDAC) möchte ich diese Aussage hier trotzdem nicht so stehen lassen, denn sie stimmt so einfach nicht. Die originale libmysql ist seit Sun-Zeiten bis heute GPL-lizensiert und würde CAO (1.4.x) zwingen, seine Quelltexte zu veröffentlichen oder aber eine (unverschämt teure) Lizenz zu kaufen. Der schnittstellenkompatible MariaDB Connector dagegen steht unter der LGPL, welche das Einbinden in Closed-Source-Programme erlaubt. Siehe dazu auch
https://mariadb.com/kb/en/mariadb/about ... nnector-c/ Der MariaDB Connector wurde von Grund auf neu geschrieben und enthält keine Bestandteile der libmysql. Er könnte also mit CAO 1.4.x verwendet werden für solche Experimente.
Nicht dass das nun etwas an der Tatsache ändert, dass CAO 1.4.x nie für den Einsatz mit aktuellen Mysql-Versionen geeignet sein wird. Denn Mysql 5.5 ist ja auch nicht mehr unbedingt das neueste und sein Support wird auch schon wieder fraglich. Viele Linux-Distributionen werfen Mysql raus und setzen komplett auf MariaDB.
Ich habe selbst vor etlichen Jahren selbst schon mal genau das selbe Experiment mit einem gepatchten Mysql 5.4 durchgeführt. Es ist ein netter Zeitvertreib, aber für den professionellen Einsatz denkbar ungeeignet. Denn dann müsste Thoren auch noch einen gepatchten Server ausliefern und pflegen. Von Lizenzfragen mal ganz abgesehen würde das jeden vernünftigen Kosten-Nutzen-Rahmen sprengen.
Re: MySQL 5.5 Prove of Concept
Verfasst: Mo 7. Aug 2017, 12:20
von Richman
Ich nutze einen ungepatchten Mysql 5.5 Server.
Die version libmysql.dll 3.23 bis version .58 ist unter LGPL lizensiert, nur die späteren versionen sind GPL. Ich nutze die Version LGPL 3.23.49 von libMySql, daher verstehe ich nicht die rechtlichen Bedenken.
Die libmysql 3.23.58 funktioniert mit MySQL bis version 5.6, 5.7 funktioniert nicht, weil die Option oldpassword entfernt wurde. MariaDB besitzt auch in der neuesten Version die Funktion oldpassword und sollte daher funktionieren (nicht getestet, weil für meien Zwecke MySQL 5.5 ausreicht.
Das CAO ohne Patch nicht mit Mysql >4.1 läuft liegt an einigen wenigen SQL SELECT statements die von SQL versionen grösser 4.1 anders verarbeitet werden.
Beispiel:
Aktuelles Statement funktioniert nur bis Version 4.1
Select... SOLL_NTAGE-TO_DAYS(CURDATE())<0 as UEBERFAELLIG ...
Aktualisiertes Statment das mit allen MySQL versionen funktioniert
Select... CAST(SOLL_NTAGE-TO_DAYS(CURDATE())<0 AS LONGLONG) as UEBERFAELLIG ...
Re: MySQL 5.5 Prove of Concept
Verfasst: Mo 7. Aug 2017, 12:39
von hh-cm
N. Lange hat geschrieben:hh-cm hat geschrieben:....denn sie stimmt so einfach nicht. Die originale libmysql ist seit Sun-Zeiten bis heute GPL-lizensiert und würde CAO (1.4.x) zwingen, seine Quelltexte zu veröffentlichen oder aber eine (unverschämt teure) Lizenz zu kaufen....
Das stimmt ebenfalls nicht. Die von CAO 1.4 genutzte libmysql ist unter LGPL gestellt. Daher weder Quelltexte noch Lizenz.
Egal was hier weiter über Librarys oder Lizenzen geredet wird, die Komponenten der 1.4 können damit nicht umgehen.
Also ist jegliche Diskussion irrelevant.
Die 1.5 baut eine direkte Verbindung ohne Lib auf. Selbst dazu gibt es seitens Sun keine konkrete aussage ob eine kommerzielle Software erlaubt ist oder nicht.
Daher richten wir uns auf MariaDB aus und durch die Unidac-Komponente wäre auch Firebird oder PostgreSQL denkbar.
Re: MySQL 5.5 Prove of Concept
Verfasst: Fr 11. Aug 2017, 08:10
von Seek51
Ich habe meine MariaDB schon seit einer Ewigkeit mit CAO am laufen.
Ich gebe einfach eine gefacte Version zurück.
Der Rest funktioniert bei mir problemlos.
Alternativ kann man die 4.1er DB auch auf einem Raspberry PI aufsetzen.
http://forum.cao-faktura.de/viewtopic.php?f=5&t=4308
Re: MySQL 5.5 Prove of Concept
Verfasst: Mi 16. Aug 2017, 11:44
von N. Lange
hh-cm hat geschrieben:Die von CAO 1.4 genutzte libmysql ist unter LGPL gestellt. Daher weder Quelltexte noch Lizenz.
Egal was hier weiter über Librarys oder Lizenzen geredet wird, die Komponenten der 1.4 können damit nicht umgehen.
Also ist jegliche Diskussion irrelevant.
Da haste auch wieder nur halb recht :-) Es ging ja ausdrücklich um MySQL 5.x und da läuft man mit CAO 1.4 und libmysql <= 3.58 vor den Baum wegen OLD PASSWORD. Von MariaDB habe ja nicht
ich gesprochen... Wir können jetzt end- und sinnlos weiter diskutieren. Es führt zu nix.
hh-cm hat geschrieben:Die 1.5 baut eine direkte Verbindung ohne Lib auf. Selbst dazu gibt es seitens Sun keine konkrete aussage ob eine kommerzielle Software erlaubt ist oder nicht.
Daher richten wir uns auf MariaDB aus und durch die Unidac-Komponente wäre auch Firebird oder PostgreSQL denkbar.
Mit UniDAC seid ihr schon auf dem richtigen Weg. Die nutze ich in meinen Projekten auch (nachdem mich Thoren vor Jahren auf den Geschmack gebracht hat!!!) Bzgl. des "direkt Andockens" an eine MySQL müsst ihr euch wahrscheinlich keine Sorgen machen. Da gibt es v.a. in den USA seit Jahren eine recht einheitliche Rechtsprechung: Schnittstellen sind nicht patentierbar und werden auch vom DMCA nicht erfasst.