Leidige Thema MySQL 5

Ein leidiges Thema um die MySQL 5.x Unterstützung ich weiß, doch es wird immer dringlicher.

Der Grund z.B. bei mir, es laufen auf den Rechner zwei MySQL Datenbanken 5.5 und 4.1 an sich noch kein Problem der Ressourcen verbrauch ist ja nicht so schlimm, doch seit PHP 5.3 kommt ein neues Problem hinzu mysql_connect kann nicht mehr mit dem alten Password Hash, leider laufen bei mir PHP Scripte die den Artikelbestand aktualisieren usw

Ich bin mir auch des Problems mit den Nutzungsbedingungen von MYSQL bewusst, aber z.B. Nusphere hat bei PHPED (kommerzielles Produkt) auch einen Weg gefunden, die Mysql 5 Unterstützung rechtlich OK einzubauen ohne die Lizenzen an Oracle/Mysql AB zahlen zu müssen.

Die gehen wie folgt vor, der Nutzer muss dazu die mysqllib.dll von mysql 5.x in ein bestimmtes Verzeichnis kopieren, respektive den Pfad dazu in den Settings angeben, eventuell noch den Mysql Connector installieren, dann funktioniert es.

Wäre das eventuell auch eine Möglichkeit für zukünftige CAO Versionen? Meine die Unterstützung für das alte Passwort Hash Format wird wohl auch bei den Connectoren anderer Programmiersprachen immer weniger werden und so sind Leute die auf Eigenentwicklungen für bestimmte Zwecke angewiesen sind früher oder später aufgeschmissen

Soll aber keine Kritik an CAO sein sondern nur eine Anregung, denn was würde ich ohne CAO-FAKTURA machen

Die Entwicklung geht in Richtung native Unterstützung, also ohne DLL.

Wie sagt Thoren das immer so schön? Its done when its done.

Die Entwicklung geht in Richtung native Unterstützung, also ohne DLL.

Sorry, ich bin nur Hobby-Scripter, aber wie soll ein Datenbank Zugriff 'nativer' gehen als über eine natives Functions Library?

Ich warte gern bis es soweit ist, aber Andere denke ich werden das Umsteigen in Erwägung ziehen, weil halt heutzutage MySQL 4.1 keine wirkliche Option mehr für Viele ist

... weil halt heutzutage MySQL 4.1 keine wirkliche Option mehr für ...

Versteh ich nicht ganz. Bei uns läuft CAO auf einem SBS2012 (64bit) mit MySQL 4.1 ohne Probleme. Auch ODBC-Anbindung funktioniert über Office 2013. Und auch das von Dir genannte Problem mit PHP scheint bei uns unter V5.3.26 nicht aufzutauchen. Damit sind wir doch wohl noch ein paar Jahre sicher oder? Oder hast Du weitreichendere Anforderungen?

Helmut.

aber wie soll ein Datenbank Zugriff 'nativer' gehen als über eine natives Functions Library?

Ohne eine Library.

Moin,

rein von den Lizenzbestimmungen fallen Lizenzkosten an, wenn mysqllib.dll von mysql 5.x genutzt wird, keine andere Datenbank als MySQL genutzt werden kann und das Programm nicht OpenSource ist.

Wie Chris schon sagte, wir arbeiten dran. Es dauernd nunmal seine Zeit, denn 35MB Quellcode baut man nicht mal eben um.

Wenn du Probleme hast, mit PHP und OLDPASSWORD eine Verbindung aufzubauen, dann leg einen neuen Datenbankbenutzer an und setzt die Kennwortverschlüssel für diesen Benutzer nicht auf OLDPASSWORD um.

Wie Chris schon sagte, wir arbeiten dran. Es dauernd nunmal seine Zeit, denn 35MB Quellcode baut man nicht mal eben um.

Schon verständlich es will ja nicht nur der Quellkode angepasst werden, beim debuggen ergeben sich immer Dinge die nicht schnell mal Pi mal Daumen zu lösen sind.

Wenn du Probleme hast, mit PHP und OLDPASSWORD eine Verbindung aufzubauen, dann leg einen neuen Datenbankbenutzer an und setzt die Kennwortverschlüssel für diesen Benutzer nicht auf OLDPASSWORD um.

Danke für den Tipp, vor lauter --old-passwords habe ich nicht gemerkt dass man ja bei 4.1 mit Usern zweier Hash Längen gleichzeitig arbeiten kann, sorry aber nochmal Danke für den Hinweis!

Schon verständlich es will ja nicht nur der Quellkode angepasst werden, beim debuggen ergeben sich immer Dinge die nicht schnell mal Pi mal Daumen zu lösen sind.

Alleine da hakt es schon. MySQL > 3 ist nicht MySQL 5. Das hat mit debuggen nichts zu tun.
Als PHP (Hobby) Scripter kennt man Integer.
Tinyint, Integer, LargeInt, SmallInt, BigInt, Boolean. (In MySQL alles Integer Felder.) nutzt man nicht.
In CAO wird es genutzt.

Wie gesagt. 35MB Quellcode sind anders zu behandeln als ein PHP Script. (Das ding will ich sehen )

MySQL > 4 wird kommen. (Sobald es fertig ist )

Also ich habe hier lokal CAO auf MySQL4, und andere Programme auf MysQL5, sowie PHP 5.3 laufen, das geht völlig problemlos.

Das einzige kleine Problemchen ist wirklich das mit dem Datenbank Passwort. Dann benutzt man eben "OLDPASSWORD" oder vergibt im Zweifelsfall eben gar kein Datenbank Passwort. Man kann ja dann z.B. den Zugriff auf bestimmte IP Adressen begrenzen.

Alleine da hakt es schon. MySQL > 3 ist nicht MySQL 5. Das hat mit debuggen nichts zu tun.

Ich meinte ja auch nach der Umsetzung die 'Eigenheiten' die jede neue/andere DB Engine so an den Tag legt, halt so im Spezifischen (Stack Overflow etc.)

Als PHP (Hobby) Scripter kennt man Integer.
Tinyint, Integer, LargeInt, SmallInt, BigInt, Boolean. (In MySQL alles Integer Felder.) nutzt man nicht.
In CAO wird es genutzt.

Wurde mir schmerzlich bewusst als ich Damals mit meinem Script begann, habe das über spezielle Filter Routinen gelöst (z.B. Time Format-, Zeichensatz-Konvertierung etc.), meine für meinen Bedarf reicht es, natürlich für die Weitergabe wäre das Nichts, zu unsicher und fehleranfällig.

Mein Script hat ja nicht einmal eine Plausibilitätsprüfung zur Absicherung eingebaut, nur eine einfachstes Errorhandling

Wie gesagt. 35MB Quellcode sind anders zu behandeln als ein PHP Script. (Das ding will ich sehen )

Natürlich, kenn das noch von ganz Früher, habe mal an AdeptXBBS mitgearbeitet, waren 'nur' ca. 4 MB Quellcode (C und C++ gemischt) , das war schon fast zuviel für mich

Bei Delphi, wenn ich mich nicht täusche, dürfte ihr ja auch noch mit den Problemen die der alte Kompiler hatte rumärgern (glaube 2 GB Speichergrenze oder so, vor dem Stack Overflow).

Embarcadero Delphi habe ich mir mal angeschaut, für meiner Einer etwas zu viel was ich nicht kann.

Nochmal Thanx an Alle die mir Tipps zu meinem Problem gaben!

Soo..
ich denke man kann hier schließen.