Hallo Zusammen
ich versuche seit gestern Fakturama 2.0.4 mit mariaDB zu verbinden.
Fehlermeldung in der log Datei:
"couldn't create or update database"
MariaDB (10.3.15) läuft auf rasperrypi mit Archlinux. Beim ersten Zugriff wurden die Tabellen in der Database angelegt, so dass die Zugangsdaten und Rechte in Ordnung sein sollten. Zugriff per HeidiSQL mit den gleichen Zugangsdaten funktioniert.
Fehler tritt sowohl unter Linux als auch unter Win7-32 auf.
Anschließend habe ich versucht mit MariaDB (10.1.15) auf debian 9.4 in virtualbox zu verbinden, gleicher Fehler.
Beim nächsten Versuch mit mysql 5.5 auf debian 8.1, hat der Zugriff auf beiden Systemen sofort funktioniert.
Da es für archlinux und debian9 in den offiziellen repos kein mysql mehr gibt würde ich mariaDB bevorzugen.
Gruß
Dieter
Ich werde nie begreifen warum man für Produktivsysteme Arch Linux nutzt.
Das aber nur am Rande ...
Ich empfehle Debian vorzuziehen, oder Ubuntu Server. Das klappt hervorragend mit MySQL.
Allerdings muss phpMyAdmin manuell ein Update unterzogen und 2 Stellen in der Config angepasst werden.
MySQL und auch Maria sind in der Standardinstallation nicht für den Zugriff von anderen Rechnern konfiguriert. Um das zu ermöglichen muss in der Conf die IP auf 0.0.0.0 gesetzt werden. Der Datenbankuser muss das recht haben von einem anderen rechner auf die Datenbank zugreifen zu dürfen. Insbesondere bei Maria lässt sich das über Heidi konfigurieren.
------------------------------------------------------------
Fakturama 2.0.3
Ubuntu@WAN 16.04.8 | Win10@LAN 20.04| MySQL 5.7.26@UbuntuServer 18.04.3 | QRK
------------------------------------------------------------
dass es bei mir mit mysql funktioniert hatte ich ja geschrieben, aber eben nicht mit mariaDB, und mysql gibt es in debian9 in den offiziellen repos nicht mehr.
Fernzugriff ist selbstverständlich aktiviert und funktioniert mit HeidiSQL ja auch mit dem Datenbankuser den ich für Fakturama angelegt habe. Die Zugriffsrechte für den DB-User sollten in Ordnung sein, sonst könnten die Tabellen von Fakturama ja nicht angelegt werden.
Gibt es in mariaDB sonst noch irgendwas zu konfigurieren, was ich übersehen habe???
Gruß
Dieter
Gebe dem fakturama datenbank user mal alle Rechte und probiere dann noch mal.
------------------------------------------------------------
Fakturama 2.0.3
Ubuntu@WAN 16.04.8 | Win10@LAN 20.04| MySQL 5.7.26@UbuntuServer 18.04.3 | QRK
------------------------------------------------------------
hab mit phpmyadmin nochmal kontrolliert, steht alles auf Yes. Hab trotzdem nochmal mit
"grant all privileges on *.* ..." auch alle mariadb Databases frei gegeben. Leider keine Änderung. Nochmal komplett neuen user angelegt wie oben, leider auch keine Änderung.
So aus der Ferne weiß ich auch keinen Rat weiter. Evt. habe ich morgen etwas zeit und könnte mir das per Anydesk anschauen.
------------------------------------------------------------
Fakturama 2.0.3
Ubuntu@WAN 16.04.8 | Win10@LAN 20.04| MySQL 5.7.26@UbuntuServer 18.04.3 | QRK
------------------------------------------------------------
OK, danke erst mal für Deine Unterstützung.
hat sich erst mal erledigt, hab jetzt ubuntu-server und mySQL 5.7 installiert, damit hat es wieder sofort funktioniert.
Gratulation 😉
------------------------------------------------------------
Fakturama 2.0.3
Ubuntu@WAN 16.04.8 | Win10@LAN 20.04| MySQL 5.7.26@UbuntuServer 18.04.3 | QRK
------------------------------------------------------------
Nachtrag:
nach einigem Testen läuft Fakturama inzwischen auch mit mariaDB.
Das Problem tritt übrigens nur bei mariaDB auf Linux Rechnern auf, mariaDB auf Windows hat bei mir mir auch direkt funktioniert.
Lösung ist der Tipp von Maho aus diesem Thread. https://www.fakturama.info/community/fakturama-2/umschalten-auf-mysql,10892
mysqldump die Fakturama Database aus mySQL exportieren, und anschließend in mariaDB importieren.
Ich hatte das gleiche Problem, (MariaDB 10.3.17 auf Raspberry PI 3B; Fehlermeldung !MESSAGE couldn't create or update database!), und habe die Lösung (für mich) gefunden:
MySQL nutzt als Standard die Kollation latin1. Ich hatte allerdings beim Erstellen der Datenbank utf8_general_ci gewählt.
Eine neue Datenbank mit der Kollation latin1_general_ci behebt das Problem.