[Gelöst] DBLog SQLite Problem: st execute_array failed

[DS_Starter]

Hallo Ralli,

dein Lösungsansatz war genau richtig.
Ich mag momentan nicht einschätzen welche Daten Telegrambot geschrieben hat, aber wenn du im DbLog das Attr useCharfilter = 1 setzt, werden nicht-ASCII Zeichen  gefiltert.
Sollten die TelegramBot-Daten für dich wichtig sein, könnte das Attr dir helfen und du das Device/Reading wieder loggen.

Grüße,
Heiko

[Knallfrosch]

Hallo,

ich scheine eine ähnliches Problem zu haben, komme aber irgendwie nicht mit der Lösung klar.

1. Ich habe ganz frisch dbLog eingerichtet. (FHEM auf Raspberry 3b+ (aktuell) und MariaDB10 mit phpMyAdmin auf Synology NAS 923+ (aktuell)
2. Als erstes bekam ich eine Fehlermeldung, dass VALUE zu lang ist und habe in der Datenbank die Zeichenkette von 32 auf 128 erweitert. Das war damit dann wohl erledigt.
3. Ich habe im configCheck den Hinweis erhalten, dass ich auf von UTF8 auf utf8mb4 umstellen sollte. Das scheint seither zu passen.
4. ich wollte "alle" Werte in die DB schreiben und habe daher das Device so: define logdb DbLog ./db.conf .*:.*  angelegt.
5. Ich erhalte damit dann aber folgende Fehlermeldung:

Code Auswählen Erweitern

2023.07.31 10:17:09 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 11617 generated 392 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:17:35 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 11726 generated 392 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.
Daraufhin habe ich die Daten für die Datenbank mit: ./db.conf .*:(humidity|temperature).*
reduziert. Ergab aber die gleiche Fehlermeldung im LOG.

Erst als ich nun im DEF nur noch ./db.conf .*:(humidity).*  stehen habe, werden die Humidity-Daten ohne Fehlermeldung in die Datenbank geschrieben.

Wie schaffe ich es nun, das alle Daten in die DB geschrieben werden können?

Die hier im Thread genannten Attr habe ich versuchsweise gesetzt, aber leider ohne Erfolg.

Hier mal das List:

Code Auswählen Erweitern

Internals:
   COLUMNS    field length used for Device: 64, Type: 64, Event: 512, Reading: 64, Value: 128, Unit: 32
   CONFIGURATION ./db.conf
   DEF        ./db.conf .*:(humidity).*
   FD         5
   FUUID      64c76571-f33f-a358-bd28-60d53fff9890affa
   FVERSION   93_DbLog.pm:v5.9.0-s27617/2023-05-25
   MODE       asynchronous
   MODEL      MYSQL
   NAME       logdb
   NR         2
   NTFY_ORDER 50-logdb
   PID        928
   REGEXP     .*:(humidity).*
   SBP_PID    929
   SBP_STATE  running
   STATE      connected
   TYPE       DbLog
   UTF8       1
   dbconn     mysql:database=fhem;host=192.168.178.34;port=3306
   dbuser     fhemuser1
   eventCount 77
   HELPER:
     COLSET     1
     DEVICECOL  64
     EVENTCOL   512
     OLDSTATE   connected
     PACKAGE    main
     READINGCOL 64
     TC         current
     TH         history
     TYPECOL    64
     UNITCOL    32
     VALUECOL   128
     VERSION    5.9.0
   OLDREADINGS:
   READINGS:
     2023-07-31 11:40:52   CacheOverflowLastNum 0
     2023-07-31 10:21:18   CacheOverflowLastState normal
     2023-07-31 11:40:52   CacheUsage      1
     2023-07-31 11:40:52   NextSync        2023-07-31 11:41:22 or when CacheUsage 500 is reached
     2023-07-31 11:40:52   state           connected
Attributes:
   asyncMode  1
   room       Interface
   useCharfilter 1
Und configCheck:

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.0067 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' = 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
Wie kann ich diesen Fehler beseitigen?

Vielen Dank.

Grüße

[DS_Starter]

Die Meldung:

Code Auswählen Erweitern

2023.07.31 10:17:09 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 11617 generated 392 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:17:35 2: DbLog logdb - Error table history - DBD::mysql::st execute_array failed: executing 11726 generated 392 errors [for Statement "INSERT INTO history (TIMESTAMP, DEVICE, TYPE, EVENT, READING, VALUE, UNIT) VALUES (?,?,?,?,?,?,?)"] at ./FHEM/93_DbLog.pm line 3211.

ist zu generisch um die genaue Ursache zu erkennen. Man sieht mehr wenn im DbLog verbose 4 oder 5 (extrem viele Ausschriften) eingestellt wird.

Aber deine Spaltengrößen passen noch nicht alle zur Applikation.
Mit phpMyAdmin  kannst du sie anpassen:

Code Auswählen Erweitern

alter table history modify DEVICE varchar(64);
alter table history modify TYPE varchar(64);
alter table history modify READING varchar(64);

alter table current modify DEVICE varchar(64);
alter table current modify TYPE varchar(64);
alter table current modify READING varchar(64);

Danach FHEM am besten mal restarten um den Cache zu leeren.
Wenn dann immer noch Fehler gemeldet werden muß man tiefer schauen.

[betateilchen]

Hallo Heiko,

mach Dir nicht weiter einen Kopf Das Thema ist inzwischen erledigt. Erstens ging es um mysql und zweitens um eine komplett falsch angelegte Datenbank.

https://forum.fhem.de/index.php?topic=134451.0

[Knallfrosch]

Aber deine Spaltengrößen passen noch nicht alle zur Applikation.
Mit phpMyAdmin  kannst du sie anpassen:

Hallo,

danke für deine Antwort.

Ich hatte mich beim Anlegen der Datenbank total verrannt.
Da haben sich einige Fehler aufsummiert.

Nachdem ich wieder neu angefangen habe und auch die Tabellen korrigiert hatte, hat es geklappt.

Grüße