Systemmodul DSGVO erzeugt Datenbankmeldung

[KJoe]

Hallo,

bei uns erzeugt das DSGVO Log Modul Fehler beim Aktualisieren von vorhandenen Einträgen in der Datenbank.
z.B. 1062 - Duplicate entry '53065-2' for key 'PRIMARY'  >> Kunde 53065 konnte nicht aktualisiert werden.

Hat das noch jemand? Und gibts ne Abhilfe?
Wir haben schon das Modul deinstalliert, alle 3 dazugehörigen Tabellen aus der DB gelöscht und es neu installiert.
Danach ging es ne Weile fehlerfrei.

Wir nutzen:
v2.0.7.2 rev 14622 dated: 2022-07-04
Datenbank Version: "MOD_2.0.7.2"

Vielen Dank im Voraus.
KJoe

Linkback: https://www.modified-shop.org/forum/index.php?topic=42726.0

[Karl1]

Hallo KJoe,
wenn du das Systemmodul "DSGVO" meinst, dann werden dort nur 2 Tabellen (`content_dsgvo`, `customers_dsgvo`) und nicht 3 installiert.

Bei dir sind aber die Kunden-IDs "53065-2" seltsam.
Die "customer_id" ist in der Datenbank AUTO_INCREMENT und Ganzzahl, da sollte eine ID mit "...-2" nicht möglich sein.

Im Modul DSGVO wird die "$_SESSION['customer_id']" als Integer (Ganzzahl) verarbeitet.
Wenn du also einen Kunden mit der ID "53065-2" hast, dann versucht das DSGVO-Modul den Kunden mit der ID "53065" zu aktualisieren.

Gruß Karl

[KJoe]

Gesundes neues Jahr,

Auch über den Jahreswechsel gab es mal wieder einige DATA BASE ERRORS seitens des DSGVO Moduls bei uns.

Hier mal ein Beispiel für den Kunden 53071. Die -2 bezieht sich wahrscheinlich auf die Contentgruppe. Denn die ist bei allen Usern gleich.  In der Tabelle  content_dsgvo ist pro Usergruppe die Content Gruppe 2 zugeordnet mit jeweils dem selben hashwert.

Hier mal der genaue Wortlaut für den Kunden 53071:

Code: PHP  [Auswählen]

1062 - Duplicate entry '53071-2' for key 'PRIMARY'

INSERT INTO customers_dsgvo (customers_id, content_group, date_confirmed) VALUES ('53071', '2', '2022-12-30 11:09:48')

Request URL: ...

[XT SQL Error]

Die Kuriosität ist jedoch - genau der Eintrag der Fehlermeldung ist in der Datenbank vorhanden.
Da Fehlermeldungen jedoch nicht von ungefähr her kommen, würden wir schon gern die Ursache finden... Hir gibt es  jedoch keine Gemeinsamkeiten bis auf die Fehlermeldung, das der Eintrag nicht erzeigt werden konnte.

Die aufgerufenen URLs sind bisher alle fehlerfrei vorhanden gewesen, also auch kein Fehler wegen aus den Favoriten des Users aufgerufenen Artikeln.  Es gibt auch keine https Fehler in den aufgerufenen URLs.

Wir sind einfach überfragt und wollten mal hören, ob noch jemand mit dem selben Phänomen unterwegs ist.
Danke im Voraus, Joe

[EDIT Tomcraft 08.06.2023: Log-Meldung mit Code-Tags versehen.]

[Q]

Sind das "frische" Kunden oder Gastkonten? Dann könnte es ein Problem mit dem Hochzählen der  customers_id sein. Das hatten wir schon mal. Welches Datenbanksystem in welcher Version verwendest du? Ist die Storage Engine für die Tabelle customers_id auf MyISAM oder InnoDB?

[KJoe]

Die Tabelle customers läuft bei uns als INNO
Es betrifft Kunden und auch Gastaccounts. Hab grad enoch mal alle Meldungen der letzten 2 Wochen gecheckt.
Es gibt keinen sichtbaren Zusammenhang welche Kunden/Gäste den DB-Error Eintrag auslösen...

Edit: Jedoch sind alle "Fehler" korrekt in der Tabelle customers_dsgvo mit dem angeblichen Fehlerwert vorhanden  
v2.0.7.2 rev 14622 dated: 2022-07-04
Datenbank Version: "MOD_2.0.7.2"

[Q]

Es wird ja auch versucht ein zweites Mal den Eintrag in die DB zu schreiben (Dublicate). Schau mal, ob du Bestellungen mit gleicher customers_id, aber unterschiedlichen Adressen hast. Z.B customers_id = 53071.
Mit DB Version meinte ich z.B. MySQL 5.3 oder MariaDB 10.1 oder so.

*edit* Schau auch mal hier: BUG IM SHOP? BESTELLUNGEN WERDEN DEM FALSCHEN KUNDEN ZUGEORDNET

[KJoe]

Bei Bestellungen haben wir keine Dreher.
Nur das DSGVO-Modul versucht ab und zu eine Doublette zu schreiben - Grund unbekannt...

Serverkombi ist PHP8.1 mit MySQL 5.7.40.

[Q]

Ich vermute trotzdem den o.g. Fehler. Die DB Version würde passen. Stelle die Tabelle customers   auf MyISAM und beobachte weiter.

[KJoe]

engine auf MyISAM geändert. Ich beobachte.
Danke schon mal. 

[Karl1]

Hallo Joe,
kann dein Problem leider nicht nachvollziehen.

Bitte poste mal eine komplette Fehlermeldung.
Beim Fehler "duplicate entry" sollte irgendwo auch"... first entry ..."  stehen und Verweise zu Dateien und Zeilen die aufgerufen werden.
Es gibt Unterschiede in der Verarbeitung in den Dateien dsgvo_action.php und dsgvo_create.php.

Schau auch in die Datenbanktabelle "configuration" was als bei dem "configuration_key" "MODULE_SYSTEM_DSGVO_CONTENT" als "configuration_value" steht.

Gruß Karl

[KJoe]

Hallo Karl,
Configuration > MODULE_SYSTEM_DSGVO_CONTENT hat den Wert > 2

Ansonsten gibt es keinerlei Hinweis auf irgendwelche Beziehungen oder das Auslösen des Fehlers.
Nach manueller löschung dachte ich noch die Fehlemeldung irgendwie mit nem gast und nen Kundenaccount reproduzieren zu können. Denkste.
Das Modul läuft scheinbar fehlerfrei., dann alle "DB-Errors" die per Mail als Duplicate (siehe Beispiel) gemeldet werden, sind nur 1x und auch sauber eingetragen...

Mein Gedanke geht grad in die andere Richtung.
Können User mit Keksblockern solch eine Fehlermeldung auslösen, wenn dadurch ein entsprechendes Feedback des Browsers fehlt?

[noRiddle (revilonetz)]

[..]
Das Modul läuft scheinbar fehlerfrei., dann alle "DB-Errors" die per Mail als Duplicate (siehe Beispiel) gemeldet werden, sind nur 1x und auch sauber eingetragen...
[..]

Du scheinst nicht zu verstehen. Q hat versucht es dir zu erklären. Es ist nicht verwunderlich, daß die "nur 1x .. sauber eingetragen" sind. Das ist logisch, denn das ist der Grund warum die "Duplicate entry"-Meldung kommt, eben weil der Eintrag bereits vorhanden ist.

Du gehst auch nicht wirklich auf Qs Sache mit der InnoDB-Engine ein (siehe sein verlinkter Thread).
Mache doch mal genau das:

[...]
Schau mal, ob du Bestellungen mit gleicher customers_id, aber unterschiedlichen Adressen hast. Z.B customers_id = 53071.
[...]

Deine Antwort

Bei Bestellungen haben wir keine Dreher.

ist keine Antwort darauf.

Gruß,
noRiddle

[KJoe]

Hallo noRiddle, ich habe leider keinen Plan, was du genau als Antwort von mir erwartest. 

Ich habe den verlinkten Beitrag genau durchgelesen. Dies ist bei uns nicht der Fall.
Wir haben keinen erkennbaren Bug in der Customers Tabelle und auch keinen in der Orders Tabelle. Alle Gast- und KundenIDs sind mit der korrekten Bestellung verknüpft.
Wir haben keine Doppelungen und auch keine Aussetzer, die das Duplicate erzeugen können. Alle Beziehungen stimmen... 

Die Engine der Tabelle Customers habe ich gestern direkt nach dem Hinweis wie gewünscht von INNO auf MyISAM geändert.

Allerdings tauchte auch gestern Abend mit MyISAM zwischendurch auch wieder eine einzelne Duplicate Mail auf.
Es betrifft die ID: 53104. Alle 10 folgenden IDs und 33 IDs davor haben keinen Fehler erzeugt.

Eintrag Database Error Mail: 53104 2 2023-01-02 19:08:33
Eintrag Tabelle cust_dsgvo: 53104 2 2023-01-02 19:08:42

Die Mail mit dem Duplicate Hinweis ist laut Zeitstempel 9 Sekunden jünger als der Eintrag in der Datenbank.
Kann das irgendwie weiter helfen?

Wir haben mittlerweile die Vermutung, dass gar kein Fehler im System auftritt, sondern nur die Fehlermeldung fälschlicherweise erzeugt wird?

VG Joe

[Karl1]

Hallo Joe,
in deinem Fall handelt es sich nicht um eine Fehlermeldung, sondern um eine Warnung, die in etwa so aussieht (nachgestellt durch doppelten Insert-Befehl).

Code: PHP  [Auswählen]

[2023-01-03 13:44:53]   [warning]       [modified]      [pid:9232]      WARNING found for URL: /login.php?action=dsgvo  {}      {}
[2023-01-03 13:44:53]   [warning]       [modified]      [pid:9232]      1062 - Duplicate entry '2-2' for key 'PRIMARY'<br/><br/>INSERT INTO customers_dsgvo (customers_id, content_group, date_confirmed) VALUES ('2', '2', now()) in File: xxx\inc\db_functions_mysqli.inc.php on Line: 161    {}      {}
[2023-01-03 13:44:53]   [warning]       [modified]      [pid:9232]      Backtrace #0 - xxx\inc\db_functions.inc.php called at Line 76   {}      {}
[2023-01-03 13:44:53]   [warning]       [modified]      [pid:9232]      Backtrace #1 - xxx\includes\external\dsgvo\modules\dsgvo_action.php called at Line 33   {}      {}
[2023-01-03 13:44:53]   [warning]       [modified]      [pid:9232]      Backtrace #2 - xxx\includes\extra\application_top\application_top_end\99_dsgvo.php called at Line 11    {}      {}
[2023-01-03 13:44:53]   [warning]       [modified]      [pid:9232]      Backtrace #3 - xxx\includes\application_top.php called at Line 341      {}      {}
[2023-01-03 13:44:53]   [warning]       [modified]      [pid:9232]      Backtrace #4 - xxx\login.php called at Line 23  {}      {}
 

Mit einem kompletten Log könnte man auch die Herkunft des Problems identifizieren - scheinbar willst du das aber nicht - warum auch immer.

Noch zwei Dinge:
- Log-Meldung werden nicht fälschlicherweise erstellt.
- "Keksblocker" arbeiten nicht serverseitig.

Gruß Karl

[KJoe]

   ich / wir sind ja quasi nur Anwender mit einer Email im Postfach in Roter Schrift verfasst...
An das log Verzeichnis denken wir in solchen Fällen nicht wirklich, da der reine Geschäftsbetrieb vorgeht .

In meinem Eingangsbeitrag war mit Log die Datenbank gemeint als Kontrollspeicher der abgelegten Werte...
Hier nun das echte LOG zu diesem Vorgang aus dem entsprechenden Ordner dazu. Sorry für das Missverständnis...

Begin Log - für diesen Vorgang:

Code: PHP  [Auswählen]

[2023-01-02 19:08:34]   [warning]       [modified]      [pid:32605]     WARNING found for URL: /product_info.php?products_id=190341     {}      {}
[2023-01-02 19:08:34]   [warning]       [modified]      [pid:32605]     1062 - Duplicate entry '53104-2' for key 'PRIMARY'<br/><br/>INSERT INTO customers_dsgvo (customers_id, content_group, date_confirmed) VALUES ('53104', '2', '2023-01-02 19:08:33') in File: /is/htdocs/_xxx_inc/db_functions_mysqli.inc.php on Line: 161        {}      {}
[2023-01-02 19:08:34]   [warning]       [modified]      [pid:32605]     Backtrace #0 - /is/htdocs/_xxx_/inc/db_functions.inc.php called at Line 76      {}      {}
[2023-01-02 19:08:34]   [warning]       [modified]      [pid:32605]     Backtrace #1 - /is/htdocs/_xxx_/includes/external/dsgvo/modules/dsgvo_create.php called at Line 63      {}      {}
[2023-01-02 19:08:34]   [warning]       [modified]      [pid:32605]     Backtrace #2 - /is/htdocs/_xxx_/includes/extra/application_bottom/99_dsgvo.php called at Line 7 {}      {}
[2023-01-02 19:08:34]   [warning]       [modified]      [pid:32605]     Backtrace #3 - /is/htdocs/_xxx_/includes/application_bottom.php called at Line 49       {}      {}
[2023-01-02 19:08:34]   [warning]       [modified]      [pid:32605]     Backtrace #4 - /is/htdocs/_xxx_/product_info.php called at Line 56      {}      {}

VG Joe

[EDIT Tomcraft 08.06.2023: Log-Meldung mit Code-Tags versehen.]