Navigation

    Logo
    • Register
    • Login
    • Search
    • Recent
    • Tags
    • Unread
    • Categories
    • Unreplied
    • Popular
    • GitHub
    • Docu
    • Hilfe
    1. Home
    2. Deutsch
    3. ioBroker Allgemein
    4. SQL-adapter: Werte nicht gespeichert wegen 'duplicate entry'

    NEWS

    • Neuer Blog: Fotos und Eindrücke aus Solingen

    • ioBroker@Smart Living Forum Solingen, 14.06. - Agenda added

    • ioBroker goes Matter ... Matter Adapter in Stable

    SQL-adapter: Werte nicht gespeichert wegen 'duplicate entry'

    This topic has been deleted. Only users with topic management privileges can see it.
    • T
      Trident last edited by

      Hi,

      ich habe das gleiche Problem!

      Bin für Hilfe dankbar.

      Viele Grüße

      Trident

      1 Reply Last reply Reply Quote 0
      • Homoran
        Homoran Global Moderator Administrators last edited by

        Hallo Thierry,

        ich habe leider noch keine Ahnung von SQL-Datenbanken und daher auch nicht mit dem SQL-Adapter.

        Daher kann ich nur versuchen mit Fragen evtl. in die Richtung zu zeigen 😞

        Wenn ich das Log richtig verstehe existiert in der Datenbank ein Primärschlüssel (primary key).

        Dieser wird doppelt vergeben und so kommt es zu dem Fehler.

        Was ist das für ein Datenfeld - und wer legt es an? (Struktur und Inhalt)

        Anscheinend setzt sich dieser Schlüssel aus id und ts zusammen.

        Was sind das für werte? (255, 1458889278000) (ts=timestamp?)

        Gruß

        Rainer

        1 Reply Last reply Reply Quote 0
        • A
          aquapro last edited by

          Jip, ist timestamp. Und er ist kurz und dadurch könnte es zu doppelten Einträgen kommen.

          Aber gab es da nicht schon mal eine Diskussion.

          Schau mal http://forum.iobroker.net/viewtopic.php?f=23&t=1776, da ging es dann auch um lock, wegen gleichen Einträgen.

          Gruß

          Tino

          1 Reply Last reply Reply Quote 0
          • sissiwup
            sissiwup last edited by

            Hallo,

            der BananaPI kann keine Millisekunden auflösen (siehe letzte 000 im TS).

            Deshalb kann es keine zwei Werte in der gleichen Sekunde geben.

            Kommt bei mir auch ab und an vor, könnte man durch globalen Zähler beim berechnen des TS lösen.

            Ich glaube ist im Code auch schon kommentiert, dass da noch was zu tun ist.

            Nach dem Motto, wenn aktueller TS = letzter TS dann aktuelle TS=aktueller TS + ++globaler Zähler

            1 Reply Last reply Reply Quote 0
            • T
              tgirard last edited by

              Danke an alle! Ich glaube ich habe es jetzt verstanden:

              1. die fehlenden Werte bei den zwei Thermostaten hatte nix mit den duplicate entries zu tun. Habe die Firmware von 1.3 auf 1.4 erhöht, jetzt gehts.

              2. Die doppelten Werte habe ich noch immer, bin aber der ID nachgegangen und es handelt sich um Speicher und Auslastung von Raspberry und Banana-Pi. Diese werden nicht alle 10'000 Millisekunden, sondern häufiger gesendet. Wenn der Timestamp immer noch der gleiche ist, gibt es eine Fehlermeldung (welche aber wohl gar nicht relevant ist).

              beste Grüsse

              Thierry

              1 Reply Last reply Reply Quote 0
              • S
                Solear last edited by

                Hallo,

                ich habe dasselbe Problem. Mein Log wird zugemüllt mit EInträgen wie

                sql-0	2016-04-25 18:37:19	error	Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(6, 1461602239000, 6.83, 0, 2, 0);: Error: ER_DUP_ENTRY: Duplicate entry '6-1461602239000' for key 'PRIMARY'
                sql-0	2016-04-25 18:37:19	error	Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(5, 1461602239000, 60, 0, 2, 0);: Error: ER_DUP_ENTRY: Duplicate entry '5-1461602239000' for key 'PRIMARY'
                sql-0	2016-04-25 18:34:54	error	Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(6, 1461602094000, 6.94, 0, 2, 0);: Error: ER_DUP_ENTRY: Duplicate entry '6-1461602094000' for key 'PRIMARY'
                sql-0	2016-04-25 18:34:54	error	Cannot insert INSERT INTO iobroker.ts_number (id, ts, val, ack, _from, q) VALUES(5, 1461602094000, 61, 0, 2, 0);: Error: ER_DUP_ENTRY: Duplicate entry '5-1461602094000' for key 'PRIMARY'
                

                Was kann ich tun? So wie ich das versteh sind die Meldungen harmlos, sie besagen scheinbar nur, dass sich der Wert noch nicht geändert hat, aber es ist nicht schön wenn mein ganzes Log rot ist.

                1 Reply Last reply Reply Quote 0
                • P
                  Pman last edited by

                  Der Fehler tritt auf wenn ein Datenpunkt zwei mal in der selben Sekunde geändert wird, da nur History-ID und Timestamp als Primary key definiert sind, ein Primary key kann es aber nur einmal geben, also kann der zweite Wert nicht gespeichert werden!

                  Workaround:

                  • Entprellzeit über 1000 ms einstellen

                  Lösungen:

                  • Entprellzeit unter 1000 ms verbieten

                  => schlechte Lösung

                  • REPLACE statt INSERT

                  => schlechte Lösung, die zwar die Fehler im LOG beseitigt, aber trotzdem inkorrekt ist, da dabei ein Wert überschrieben wird. Es ist ein Sensor oder anderer Datenpunkt vorstellbar welcher seinen Wert sehr schnell ändert, dieser könnte von History nicht korrekt erfasst werden.

                  • Millisekunden implementieren

                  => erhöht zwar die zeitliche Auflösung, behebt aber nicht das eigentliche Problem. Änderungen innerhalb einer Millisekunde können trotzdem nicht erfasst werden.

                  • SQL-Schema erweitern

                  => meiner Meinung nach der einzig richtige Weg. Eine mögliche Erweiterung wäre das hinzufügen einer Spalte "counter INT" zur Tabelle und zum Primary Key. Counter wird standardmäßig mit 0 beschrieben, bei duplicate key error wird er um 1 erhöht. Beim Abrufen wird nach TS und Counter sortiert.

                  1 Reply Last reply Reply Quote 0
                  • S
                    Solear last edited by

                    Vielen Dank!

                    Habe jetzt die Entprellzeit überall auf 10000 ms (10 Sekunden) gestellt.

                    Das war zwar im SQL-Adapter voreingestellt, hat er auch für die hm-rpc-Historieeinstellungen übernommen, aber bei den Javascripts hat er überall eine Entprellzeit von 0 gehabt. Das habe ich beim aktivieren übersehen.

                    Könnte ein Bug sein, dass beim Javascriptadapter die Voreinstellungen vom SQL-Adapter beim Einstellen nicht als Voreinstellung übernommen werden?

                    1 Reply Last reply Reply Quote 0
                    • T
                      tp1de last edited by

                      Duplicate Key tritt bei mir bei Entprellzeit im Datenobjekt von 10 Sekunden auf !

                      Die Entprellzeit scheint also auch so nicht vollumfänglich zu funktionieren.

                      1 Reply Last reply Reply Quote 0
                      • S
                        Solear last edited by

                        @tom57:

                        Duplicate Key tritt bei mir bei Entprellzeit im Datenobjekt von 10 Sekunden auf !

                        Die Entprellzeit scheint also auch so nicht vollumfänglich zu funktionieren. `

                        Sind alle Objekte mit 10000 angegeben? Schau sie mal durch, bei mir waren ein paar mit 0 dabei unter Javascript.

                        1 Reply Last reply Reply Quote 0
                        • T
                          tp1de last edited by

                          Die Polling-Zeiten für Eingänge (Analoge / Digitale) liegen bei vielen Millisekunden.

                          Beim Piface bei 250 mS. Die Umstellung auf genaue Zeit mit Millisekunden würde reichen.

                          Ich schreibe ca. 30-35.000 Sätze in die DB pro Tag. Dabei habe ich aber keinen Anspruch mehrere Einträge pro Sekunde zu schreiben.

                          Das Datenobjekt um das es sich handelt ist bei mir ein digitaler Eingang des Piface Bord. Der Eingang wird über ein 220V Relais belegt.

                          Ich vermute mal, dass das Schalt-Jitter vom Relais ist. In dem Fall scheint die Entprellzeit nicht zu greifen.

                          Alle Datenpunkte mit 10 Sekunden !

                          1 Reply Last reply Reply Quote 0
                          • P
                            Pman last edited by

                            @tom57:

                            Die Polling-Zeiten für Eingänge (Analoge / Digitale) liegen bei vielen Millisekunden.

                            Beim Piface bei 250 mS. Die Umstellung auf genaue Zeit mit Millisekunden würde reichen.

                            Ich schreibe ca. 30-35.000 Sätze in die DB pro Tag. Dabei habe ich aber keinen Anspruch mehrere Einträge pro Sekunde zu schreiben.

                            Das Datenobjekt um das es sich handelt ist bei mir ein digitaler Eingang des Piface Bord. Der Eingang wird über ein 220V Relais belegt.

                            Ich vermute mal, dass das Schalt-Jitter vom Relais ist. In dem Fall scheint die Entprellzeit nicht zu greifen.

                            Alle Datenpunkte mit 10 Sekunden ! `

                            Mag sein, dass es mit Millisekunden für dich funktionieren würde aber es sollte schon für alle denkbaren Anwendungen funktionieren.

                            1 Reply Last reply Reply Quote 0
                            • First post
                              Last post

                            Support us

                            ioBroker
                            Community Adapters
                            Donate
                            FAQ Cloud / IOT
                            HowTo: Node.js-Update
                            HowTo: Backup/Restore
                            Downloads
                            BLOG

                            560
                            Online

                            31.9k
                            Users

                            80.2k
                            Topics

                            1.3m
                            Posts

                            8
                            14
                            1921
                            Loading More Posts
                            • Oldest to Newest
                            • Newest to Oldest
                            • Most Votes
                            Reply
                            • Reply as topic
                            Log in to reply
                            Community
                            Impressum | Datenschutz-Bestimmungen | Nutzungsbedingungen
                            The ioBroker Community 2014-2023
                            logo