Current

[KSTeilnehmer]

Seit der Anpassung des adodb/Datenbank Treibers bekomme ich keine Version > 1.0.33 weder bei Strato noch bei 1&1 (Hosting) zum Laufen, das db_update.php script stürzt ab.
Lt. git releaseinfo ist 1.0.34 “ready for PHP 7.4”, aber witzigerweise lief es mit 1.0.33 unter PHP 7.4 problemlos.

Irgendwer eine Idee? Wäre schade, wenn man die Updates nicht mehr machen kann.

[Emilio PaoliniAdministrator]

Huch? Das ist ja schräg. Gibt es zum “Absturz” eine verwertbare Fehlermeldung? Kannst du uns die genaue Version der verwendeten DB sagen? Wir würden das gerne weiter untersuchen.

Liebe Grüße

Emilio

[KSTeilnehmer]

Beispielhaft STRATO Hosting PRO:
MYSQL v5.7, PHP 7.4.
Nach dem LOGIN (das geht noch) kommt eine leere Seite, denke weil die Fehlermeldungen unterdrückt werden, ich starte testweise das db_update.php, Fehlerausgabe siehe Attachment.

Attachments:

You must be logged in to view attached files.

[KSTeilnehmer]

PS: Das Verhalten ist immer das selbe, egal ob die Version vorher 1.0.21 oder 1.0.33 war.
Der Knackpunkt liegt hier m.E. beim veränderten Database driver ab 1.0.34.

[KSTeilnehmer]

Hat sich schon eine Erkenntnis ergeben in irgendeiner Form?
Oder, was können wir hier sinnvoll tun oder testen, um den Prozess voranzubringen?

[KSTeilnehmer]

Zu den Datenbankversionen nochmal, und zur Einordnung:

Der “extended” community-Support für MYSQL 5.6 ist seit über einem Jahr ausgelaufen, damit ist klar, dass Massenhoster wie Strato, Ionos etc. diese Version nie mehr anbieten werden.

MYSQL 5.7 ist stabil und der community Support endet im Oktober 2023, und dann kann man sich einen Upgradepfad überlegen oder auch schauen was die Hoster machen, aber bis dahin ist 5.7 die Wahl, und damit sollte es einfach reibungslos gehen. Lief es ja auch bis zum 1.0.34.

Für das CRM eine längst ausgelaufene DB-Version vorzuhalten oder downzugraden seh ich nicht als Lösung.

[KSTeilnehmer]

Sofern es von Interesse ist:

Eine komplette Neuinstallation – 1.0.36, STRATO HOSTING PRO, PHP 7.4, MYSQL 5.7 klappt auch nicht, der Install hängt bei der Anlage der “Datenbank”, da wird keine einzige Tabelle angelegt, er bleibt einfach stehen.

/logs/installLog.txt:

[2022-07-28 11:02:07] Start config
[2022-07-28 11:02:07] End config

+++ EOF +++
Zum Logeintrag [Start Database]
und dann initschema etc. kommt es gar nicht, das stirbt schon davor.

Nett wäre irgendeine Reaktion oder Zurkenntnisnahme.

[KSTeilnehmer]

Test in der selben Umgebung wie oben, Tag 1.0.36, MYSQL 5.7, PHP 7.4.30, aber den neuen ADODB Treiber 5.22.X in /libraries/adodb mit der Version 5.20.19 ersetzt, damit läuft es augenscheinlich. (!)
20000 Datensätze in Organisationen importiert, keine Auffälligkeiten.

Lt. ADODB-Site ist 5.20 bereits kompatibel mit PHP 7.4, aber die Version 5.20.20 bringt erstmalig PHP 8 Support mit, und genau da liegt irgendwo ein Knackpunkt. Testweise Neuinstallation mit 5.20.21 legte zwar die Tables an, scheiterte aber bei der Sektion “USER”.

Was spricht dagegen, vorerst mit ADODB 5.20.19 weiterzumachen? Wenn ein Ziel war, PHP 7.4 zu unterstützen, dann war dieses bereits erreicht.

[KSTeilnehmer]

Edit (da man hier leider nicht nachbearbeiten kann)

-> Lt. ADODB-Site ist 5.20.12 bereits vollständig kompatibel mit PHP 7 und damit mit PHP 7.4.

BerliCRM 1.0.33 kommt mit ADODB 5.20.12.

[KSTeilnehmer]

Nächster Test: 1.0.36, Strato/IONOS PHP 7.4.30 gegen mit eine Standard-Distro MYSQL 5.7.39 x86_64 auf einem separaten Server – Tabellen werden noch angelegt, beim User geht es schief:

Get AdoDB instance and new Users object

und ab da kommt nichts mehr. Gegentest mit “downgrade” /libraries/adodb auf Version 5.20.19, s.o. – funktioniert sofort.

Fazit bis hierher: Solange PHP 8 nicht unterstützt werden muss, sollte dringend ein 7.4 kompatibler ADODB-Treiber – nämlich 5.20.19 – eingesetzt werden. Mag sein, dass MariaDB anders funktioniert, aber nicht alle haben oder können das einsetzen.

[Autor]

Beiträge