Probleme beim Einrichten von dbLog

[Knallfrosch]

Hallo,

ich versuche mich gerade daran dbLog einzurichten um dann über kurz oder lang vom Filelog weg zu kommen.

MariaDB10 und phpMyAdmin läuft auf meiner SynologyNAS.
FHEM auf einem Raspberry Pi 3B+.

Die Datenbank inkl. Benutzer ist auf der NAS und dem Raspi eingerichtet und lässt sich auch abfragen:
Du darfst diesen Dateianhang nicht ansehen.

Soweit so gut.

Nach dem

Code Auswählen Erweitern

define logdb DbLog ./db.conf .*:.*
Erhalte ich im STATE aber nur Fehlermeldungen die für mich leider zu kryptisch sind.

Als erstes stand etwas von "history" failed o.ä.
Also habe ich daraufhin über phpMyAdmin 2 Tabellen angelegt current und history das sieht nun wie folgt aus:

Du darfst diesen Dateianhang nicht ansehen.


Jetzt hat sich die Fehlermeldung im STATE geändert und ich erhalte folgendes:
Du darfst diesen Dateianhang nicht ansehen.

Kann mir bitte jemand hier weiterhelfen?

Welche Informationen benötigt ihr noch für die Fehleranalyse?


Vielen Dank im Voraus.

Grüße
 

 

[betateilchen]

• Falsches Unterforum für Fragen zu DbLog
• wie um alles in der Welt hast Du die Tabellen angelegt? Du kannst doch nicht sämtliche Felder mit dem Type int anlegen.

Hast Du jemals die commandref zu DbLog gelesen? Es gibt in FHEM sogar fertige sql-Skripte zum korrekten Anlegen der benötigten Tabellen.

[Knallfrosch]

Hallo,

zu 1: Ich habe das bewusst als in das Anfängerforum, da ich mich als solchen zähle. Sorry!

zu 2: Ich habe die Tabellen nach bestem Wissen händisch in phpMyAdmin angelegt, wenn das Falsch ist, wie muss ich das richtig machen?


Ich habe mich an eine gefundene Anleitung gehalten und hänge nun eben wie oben beschrieben.
Ich habe auch absolut keine Ahnung wie ich die Tabellen mit einem Script anlegen kann.
Kannst du mir dabei behilflich sein?

Das wäre super.

Grüße

[Knallfrosch]

Ich bin das jetzt nochmal durchgegangen aber finde keinen Fehler.
Vorgegangen bin ich wie folgt:

Ich habe auf dem RPi mit FHEM den MySQL Client installiert:

Code Auswählen Erweitern

sudo apt-get install mariadb-client libdbd-mysql libdbd-mysql-perl


Dann habe ich (hatte das eben als Betateilchen schrieb nicht auf dem Schirm....bin weit weg von einem ITler ) das Skript genutzt aber zuvor kopiert:

Code Auswählen Erweitern

sudo cp /opt/fhem/contrib/dblog/db_create_mysql.sql /opt/fhem/contrib/dblog/my_create_mysql.sql
und dann entsprechend

Code Auswählen Erweitern

sudo nano /opt/fhem/contrib/dblog/my_create_mysql.sqlmit abgeändertem Passwort konfiguriert.

Danach dann mit:

Code Auswählen Erweitern

sudo mysql -h "meineIP" -P 3306 -u root -p < /opt/fhem/contrib/dblog/my_create_mysql.sqldie Datenbank erstellt bzw. erstellen wollen.

Ich glaube hier liegt schon der Fehler.

Ich konnte zwar mit:

Code Auswählen Erweitern

sudo mysql -h 10.10.0.245 -P 3306 -p -u fhemuser
show databases;

Die Datenbank anzeigen aber weder die Unterordner current und history noch der User wurde auf meiner Synology angelegt.
Ich bin dann eben zwischenzeitlich hin und habe den "fhemuser" und die Tabellen händisch angelegt.

Ich verstehe nicht, warum ich mit show databases zwar einen Ordner "Fhem" finden konnte, aber der Rest nicht angelegt bzw. auffindbar ist.

Wo kann/muss ich denn hier mit der Fehlersuche beginnen?


Danke im voraus.


Grüße

[RalfRog]

Das stimmt immer noch

...
Falsches Unterforum für Fragen zu DbLog

Bin da auch eher Datenbank-Novize, aber als Denkanstoß:
das Wiki kennst du auch ? => https://wiki.fhem.de/wiki/DbLog

Für mich sieht es im ersten Post bis "Die Datenbank inkl. Benutzer ist auf der NAS und dem Raspi eingerichtet und lässt sich auch abfragen:" (großer Screenshot) eigentlich ganz gut aus. Die danach händisch angelegten Tabellen sind so auf jeden Fall verkehrt. Die angelegte Datenbank mit ihren Tabellen durch das SQL-Script zu überschreiben funktioniert vermutlich nicht.

Ich würde versuchen die händisch angelegeten Tabellen besser die Database "fhem" zu löschen (statt CREATE DATABASE `fhem` vielleicht ein DELETE) bevor ich das SQL-Script erneut ausführe. Die SQL Kommandos kannst du ja ggfs. im Client auch einzeln ausführen (der User existiert vermutlich auch schon):

Code Auswählen Erweitern

CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP) USING BTREE;
oder eben

Code Auswählen Erweitern

sudo mysql -h "meineIP" -P 3306 -u root -p < /opt/fhem/contrib/dblog/my_create_mysql.sql (IP = 10.10.0.245)
Im PHP-Admin kannst du dann schauen (nur gucken) ob die Datenbank und die beiden Tabellen (natürlich noch leer) da sind. Vor allem sind da keine Spalten vom Typ "int" (alles Text vom Typ varchar bzw. Timestamp). Oder wie im genannten Screenshot im Client abgefragt.

Dann geht es weiter mit der Einrichtung des DBLog-Devices.

[Knallfrosch]

Hallo,

danke für deine Antwort.

Nein, den Wiki-Eintrag habe ich noch nicht durchgearbeitet.
Hatte mich bisher nur Anhand der Anleitung und aus Teilen der Commandref bis zum jetzigen Stand gehangelt.

Die falschen Einstellung in den Tabellen habe ich zwar korrigiert aber das brachte leider auch keinen Erfolg.

Der Idee mit dem löschen und neu anlegen der Tabellen und User werde ich auf jeden Fall nochmal versuchen.
Aktuell scheint es ja tatsächlich daran zu hängen.

Habe aktuell auch keinen Zugriff auf mein Netzwerk und kann nichts versuchen.
Werde aber dann auch mal noch den Wiki-Eintrag zu DbLog anschauen.....vllt. finde ich dort auch meinen Stolperstein.

Grüße


PS: Ich kann m.W.n. das Unterforum nicht bearbeiten. Evtl. kann ein MOD ja meinen Thread verschieben.

[RalfRog]

PS: Ich kann m.W.n. das Unterforum nicht bearbeiten. Evtl. kann ein MOD ja meinen Thread verschieben.

Unten links oder rechts ist der Button

Edit
unten rechts unter Moderation / Thema verschieben

[Knallfrosch]

Hallo,

ich habe nun die Schritte zum Anlegen der Tabellen und des Users in der Datenbank durchgeführt.
Irgendwo hatte ich da gestern einen Wurm drin.

Jedenfalls hat es nun funktioniert, das der User und die Tabellenstruktur wie in dem Skript vorgesehen angelegt wurden.
Soweit so gut.

Auch das Device in FHEM existiert zum übertragen, aber nun hänge ich dort.

Nachdem ein paar Datensätze in der Datenbank gelandet sind hat Fhem gemeckert:

Code Auswählen Erweitern

2023.07.31 08:42:44 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: Data too long for column 'VALUE' at row 1 [err was 1406 now 2000000000]
executing 274 generated 21 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
Ich habe dann einfach versucht die "Zeichenlänge" von VALUE auf 128 zu ändern.
Danach kamen dann ein paar weitere Werte.

Nun feuert FHEM aber noch folgende Meldung raus:

Code Auswählen Erweitern

2023.07.31 09:03:06 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 8566 generated 250 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

2023.07.31 09:03:20 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 8747 generated 250 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

2023.07.31 09:03:36 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 8826 generated 250 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

2023.07.31 09:03:58 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 9064 generated 309 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.


Und hier bin ich mit meinem Latein am Ende.
Ich habe keine Idee warum diese Meldung kommt, geschweige denn, was ich dagegen machen kann.


Grüße



PS: In welches Unterforum soll ich denn meinen Thread hier verschieben?
Ich habe mal über die Suche geschaut, wo es die meisten Beiträge zu Problemen mit DbLog gibt und die finden sich quasi in allen Unterforen verteilt.

[Knallfrosch]

Im configCheck steht nun folgendes:

Code Auswählen Erweitern

Available Drivers in your system

DBD::DBM, DBD::ExampleP, DBD::File, DBD::Gofer, DBD::Mem, DBD::Proxy, DBD::SQLite, DBD::Sponge, DBD::mysql

Result of version check

Used Perl version: 5.28.1
Used DBI (Database independent interface) version: 1.642
Used DBD (Database driver) version Undefined
Used DbLog version: 5.9.0
Your local DbLog module is up to date.
Rating:
Recommendation: Update of DbLog is not needed.


Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.178.34;port=3306, User -> fhemuser1, Password -> read o.k.
Rating:

Result of connection check

Connection to database fhem successfully done.
The time required to establish the connection was 0.0102 seconds.
Rating:
Recommendation: settings o.k.

Result of collation check

Collation used by Client (connection): UTF8MB4_BIN
Collation used by DB fhem: UTF8MB4_BIN
Rating:
Recommendation: settings o.k.

Result of insert mode check

Insert mode of DbLog-device logdb is: Array
Rating:
Recommendation: settings o.k.

Result of plot generation method check

WARNING - at least one of your FHEMWEB devices has attribute 'plotfork = 1' not set.

WEB: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEB_Home: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBhabridge: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBphone: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBtablet: plotfork=0 / plotEmbed=0 / longpollSVG=0

Rating:
Recommendation: You should set attribute 'plotfork = 1' in relevant devices. If this attribute is not set, blocking situations may occure when creating plots.
(Note: Your system must have sufficient memory to handle parallel running Perl processes.) See also global attribute blockingCallMax.


Result of table 'history' check

Column width set in table history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
Recommendation: The relation between column width in table history and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCmd' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
Alternatively the field width used by logdb can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)

Result of table 'current' check

Column width set in table current: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 32, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
Recommendation: The relation between column width in table current and the field width used in device logdb don't meet the requirements. Please make sure that the width of database field definition is equal or larger than the field width used by the module. Compare the given results.
Currently the default values for field width are:

DEVICE: 64
TYPE: 64
EVENT: 512
READING: 64
VALUE: 128
UNIT: 32

You can change the column width in database by a statement like 'alter table current modify VALUE varchar(128);' (example for changing field 'VALUE'). You can do it for example by executing 'sqlCmd' in DbRep or in a SQL-Editor of your choice. (switch logdb to asynchron mode for non-blocking).
Alternatively the field width used by logdb can be adjusted by setting attributes 'colEvent', 'colReading', 'colValue'. (pls. refer to commandref)

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'TIMESTAMP', 'READING'.
Rating:
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

No DbRep-device assigned to logdb is used. Hence an index for DbRep isn't needed.
Rating:
Recommendation: settings o.k
Meine Einstellung auf utf8 wurde als "Fehler" angezeigt und ich habe wie empfohlen auf utf8mb4 geändert.
Trotzdem erhalte ich nach wie vor die oben genannten Einträge im LOG:

Code Auswählen Erweitern

2023.07.31 10:07:04 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7397 generated 255 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

2023.07.31 10:07:20 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7466 generated 257 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

2023.07.31 10:07:40 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7614 generated 257 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

2023.07.31 10:07:55 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7792 generated 257 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

2023.07.31 10:08:11 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 7831 generated 257 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

Ich komme hier nicht mehr weiter.


Grüße

[RalfRog]

PS: In welches Unterforum soll ich denn meinen Thread hier verschieben?
Ich habe mal über die Suche geschaut, wo es die meisten Beiträge zu Problemen mit DbLog gibt und die finden sich quasi in allen Unterforen verteilt.

Mach mal in der FHEM-Kommandozeile  "help dblog"

Gruß Ralf

[RalfRog]

Ich habe dann einfach versucht die "Zeichenlänge" von VALUE auf 128 zu ändern.
Danach kamen dann ein paar weitere Werte.

Im ConfigCheck werden u.a. noch zwei andere Spalten als zu kurz ausgewiesen:

Column width set in table history: 'DEVICE' = 32, 'TYPE' = 32, 'EVENT' = 512, 'READING' = 32, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32

Ist   'DEVICE' = 32, 'TYPE' = 32
Soll 'DEVICE' = 64, 'TYPE' = 64

Edit
Betrifft auch 'READING' = 64
und beide Tabellen curent & history
wie es zu ändern ist steht ja auch dabei "You can change the column width in database by a statement like 'alter table history modify VALUE varchar(128);' (example for changing field 'VALUE')."

[betateilchen]

Ich vermute ja immer noch ein Problem bei den verwendeten Datentypen.

Und es hilft der Lösungsfindung überhaupt nicht, die Diskussion jetzt auch noch in mehreren Threads parallel zu führen!

[RalfRog]

Vermutlich hast du recht.

Wenn die Kommandos

Code Auswählen Erweitern

CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32))
korrekt gelaufen wären, dürfte der configCheck die Feldlängen nicht anmeckern. Im Create sind sie ja genau wie der Datentyp korrekt. 

[Knallfrosch]

Danke, die Spaltenlänge habe ich angepasst, hatte mich zu sehr auf den LOG-Eintrag konzentriert und nur VALUE angepasst.

Nun sieht der ConfigCheck so aus:

Code Auswählen Erweitern

Available Drivers in your system

DBD::DBM, DBD::ExampleP, DBD::File, DBD::Gofer, DBD::Mem, DBD::Proxy, DBD::SQLite, DBD::Sponge, DBD::mysql

Result of version check

Used Perl version: 5.28.1
Used DBI (Database independent interface) version: 1.642
Used DBD (Database driver) version mysql: 4.050
Used DbLog version: 5.9.0
Your local DbLog module is up to date.
Rating:
Recommendation: Update of DbLog is not needed.
Your DBD version fulfills UTF8 support, no need to update DBD.

Result of configuration read check

Connection parameter store type: file
Connection parameter: Connection -> mysql:database=fhem;host=192.168.178.34;port=3306, User -> fhemuser1, Password -> read o.k.
Rating:

Result of connection check

Connection to database fhem successfully done.
The time required to establish the connection was 0.0065 seconds.
Rating:
Recommendation: settings o.k.

Result of collation check

Collation used by Client (connection): UTF8MB4_BIN
Collation used by DB fhem: UTF8MB4_BIN
Rating:
Recommendation: settings o.k. Your DBD version fulfills UTF8 support, no need to update DBD.

Result of insert mode check

Insert mode of DbLog-device logdb is: Array
Rating:
Recommendation: settings o.k.

Result of plot generation method check

WARNING - at least one of your FHEMWEB devices has attribute 'plotfork = 1' not set.

WEB: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEB_Home: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBhabridge: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBphone: plotfork=0 / plotEmbed=0 / longpollSVG=0
WEBtablet: plotfork=0 / plotEmbed=0 / longpollSVG=0

Rating:
Recommendation: You should set attribute 'plotfork = 1' in relevant devices. If this attribute is not set, blocking situations may occure when creating plots.
(Note: Your system must have sufficient memory to handle parallel running Perl processes.) See also global attribute blockingCallMax.


Result of table 'history' check

Column width set in table history: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
Recommendation: settings o.k.

Result of table 'current' check

Column width set in table current: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Column width used by device logdb: 'DEVICE' = 64, 'TYPE' = 64, 'EVENT' = 512, 'READING' = 64, 'VALUE' = 128, 'UNIT' = 32
Rating:
Recommendation: settings o.k.

Result of check 'Search_Idx' availability

Index 'Search_Idx' exists and contains recommended fields 'DEVICE', 'TIMESTAMP', 'READING'.
Rating:
Recommendation: settings o.k.

Result of check 'Report_Idx' availability for DbRep-devices

No DbRep-device assigned to logdb is used. Hence an index for DbRep isn't needed.
Rating:
Recommendation: settings o.k

Die Feldlängen wurden ja autoamtisch mit dem Skript erstellt:

Code Auswählen Erweitern

CREATE DATABASE `fhem` DEFAULT CHARACTER SET utf8 COLLATE utf8_bin;
CREATE USER 'fhemuser'@'%' IDENTIFIED BY 'fhempassword';
CREATE TABLE `fhem`.`history` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
CREATE TABLE `fhem`.`current` (TIMESTAMP TIMESTAMP, DEVICE varchar(32), TYPE varchar(32), EVENT varchar(512), READING varchar(32), VALUE varchar(32), UNIT varchar(32));
GRANT SELECT, INSERT, DELETE, UPDATE ON `fhem`.* TO 'fhemuser'@'%';
CREATE INDEX Search_Idx ON `fhem`.`history` (DEVICE, READING, TIMESTAMP);


Das war die im Ordner abgelegte Datei: /opt/fhem/contrib/dblog/
Irgendwo habe ich zwischendurch gelesen, dass diese Datei nicht aktualisiert ist. Daher haben wohl auch die Spaltenbreiten nicht gepasst.



Aktuell läuft es ohne Fehlermeldungen im LOG.

Jedoch beobachte ich, dass scheinbar der Cache voll läuft.
In der Datenbank kommen kontinuierlich Daten an, aber lt. Datenbank sind es ca. 13.000 Einträge und im listChache ist die fortlaufende Nummer bei über 20.000 Einträgen.

Du darfst diesen Dateianhang nicht ansehen.


Welche Angaben oder Screenshots wären noch sinnvoll für die Fehlersuche?

Irgendwie rutsche ich aktuell von Problem zu Problem.....kaum ist das der eine Fehler behoben taucht der nächste auf.


Grüße

[Knallfrosch]

So sieht es aktuell in phpMyAdmin aus:

Du darfst diesen Dateianhang nicht ansehen.