[gelöst] current Tabelle lässt sich nicht anlegen bei SQLite

[_fhemuser_]

Hallo,

nachdem sich meine SSD am Raspberry 3 aufgelöst hat, habe ich das System komplett neu aufgesetzt mit Raspberry Buster und den neuesten fhem Version.

Da auf dem alten System alles in eine SQL Datenbank geschrieben wurde, möchte ich das auch bei dem neuen Sytem machen, da ich unter anderem fast alle fhem Dateien sichern konnte.

Aber beim Anlegen der Tabellen in der Datenbank tritt ein Fehler auf.

Vorgegangen bin ich nach dieser Anleitung: https://wiki.fhem.de/wiki/DbLog

Sobald ich den SQL Befehl:

Code Auswählen Erweitern

CREATE TABLE `current` (`TIMESTAMP` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,`DEVICE` varchar(64) DEFAULT NULL,`TYPE` varchar(64) DEFAULT NULL, `EVENT` varchar(512) DEFAULT NULL, `READING` varchar(64) DEFAULT NULL, `VALUE` varchar(255) DEFAULT NULL, `UNIT` varchar(32) DEFAULT NULL);
eingebe, ehalte ich den Fehler: Error: near "ON": syntax error

Die history Tabelle betrifft das nicht, die ja quasi identisch ist.

Vielen Dank im Voraus.
_fhemuser_

[Waldmensch]

Funktioniert das ON UPDATE überhaupt in SQLite? M.E. Geht das nur mit Trigger. Ich wüsste auch nicht, was das ON UPDATE für einen Sinn macht. Imho wird die Tabelle doch nur fortlaufend mit INSERT geschrieben.


Gesendet von iPhone mit Tapatalk

[Otto123]

Hi _fhemuser_,
Schau mal besser in die Commandref, da ist ein link zum SVN, da sind die aktuellen Scripte enthalten.

https://svn.fhem.de/trac/browser/trunk/fhem/contrib/dblog

Gruß Otto

[amenomade]

Nimm die Befehle, die in /opt/fhem/contrib/dblog/db_create_sqlite.sql sind
Oder einfach:

Code Auswählen Erweitern

sudo sqlite3 /opt/fhem/fhem.db < /opt/fhem/contrib/dblog/db_create_sqlite.sql

[_fhemuser_]

Vielen Dank für die vielen schnellen Antworten.

Die Lösung von amenomade war die schnellste und einfachste.

Es funktioniert jetzt wieder wie gewohnt.

Dann wäre es doch vielleicht sinnvoll im Wiki im Abschnitt SQLite nur den Eintrag

Code Auswählen Erweitern

CREATE TABLE current (TIMESTAMP TIMESTAMP, DEVICE varchar(64), TYPE varchar(64), EVENT varchar(512), READING varchar(64), VALUE varchar(128), UNIT varchar(32)); einzutragen.

[Waldmensch]

Nein, der stimmt so nicht. Beim INSERT würde keine automatische Timestamp erstellt. Entsprechend ließen sich die Readings nicht mehr zeitlich zuordnen.


Gesendet von iPhone mit Tapatalk

[amenomade]

Beim INSERT von was, wie, wann, wo?

[Waldmensch]

Mit einem INSERT Kommando wird ein Datensatz in die Tabelle geschrieben. FHEM liefert dabei soweit ich weiß keine Timestamp mit. Daher muss das setzen der Timestamp von der Datenbank selbst übernommen werden. Das stellt man über das DEFAULT Attribut der Timestamp Spalte bei der Erstellung der Tabelle ein.
Im weiter oben verlinkten Skript ist es richtig. Im Codebeispiel des OP fehlt das DEFAULT Attribut.


Gesendet von iPhone mit Tapatalk

[_fhemuser_]

Wie muss den dann die CREATE Anweisung aussehen?

[Waldmensch]

Wie die, im oben verlinkten Skript. So schwer kann das doch nicht sein [emoji51]

Edit: ich sehe grad, das der DEFAULT nur in der Historie Tabelle gesetzt wird. Imho ist der Befehl für die current auch im Skript nicht richtig.

Code Auswählen Erweitern



CREATE TABLE 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));

Gesendet von iPhone mit Tapatalk

[DS_Starter]

Hallo zusammen,

muss mal kurz einhaken...

FHEM liefert dabei soweit ich weiß keine Timestamp mit. Daher muss das setzen der Timestamp von der Datenbank selbst übernommen werden. Das stellt man über das DEFAULT Attribut der Timestamp Spalte bei der Erstellung der Tabelle ein.

Das ist nicht richtig. FHEM bringt den Timestamp mit, entweder den Timestamp von CHANGETIME des Events wenn vorhanden, ansonsten den aktuellen Timestamp.

LG,
Heiko

[Waldmensch]

Dann wäre das DEFAULT in der History aber auch nicht nötig. Warum setzt man es da?
Das DEFAULT kommt nur zum Einsatz, wenn beim INSERT der Wert nicht, oder als NULL übergeben wird


Gesendet von iPhone mit Tapatalk

[DS_Starter]

Dann wäre das DEFAULT in der History aber auch nicht nötig. Warum setzt man es da?

Stimmt, wäre auch nicht nötig.
DbLog gibt es schon seit mehr als 10 Jahren und hat bestimmt eine bewegte Geschichte hinter sich. Vielleicht wurde der Timestamp früher nicht geliefert, ich kann es nicht sagen. Ich betreue das Modul erst rund 3 Jahre seit ca. Ende 2016.
Aber da es nicht stört, muss man das Erstellungsscript auch nicht ändern.

LG,
Heiko

[Otto123]

muss man das Erstellungsscript auch nicht ändern.

Hallo Heiko,

müssen wir das Wiki ändern? Da steht ja ein völlig anderes Script. Im Wiki besser bloß link zum Contrib?

Gruß Otto

[DS_Starter]

Hallo Otto,

jetzt wo du es fragst ... ich habe mir das zitierte Wiki noch garnicht komplett angeschaut. 
Ein Link zum contrib bzw. den dort hinterlegten Skripten wäre m.M. das Beste weil die sich im Zuge von Weiterentwicklungen durchaus  mal ändern können.

Schönen Wochenstart !

Grüße,
Heiko