phpBB.de

Hallo!

Seit kurzer Zeit (hatte gerade den Style bearbeitet), bekomm ich auf einmal folgenden Fehler wenn ich ins ACP möchte oder da eine Einstellung speichern möchte...

Allgemeiner Fehler
SQL ERROR [ mysql4 ]

Duplicate entry '2578' for key 'PRIMARY' [1062]

SQL

INSERT INTO phpbb_log (user_id, log_ip, log_time, log_operation, log_data, log_type) VALUES (57, '79.240.255.232', 1347742189, 'LOG_ADMIN_AUTH_SUCCESS', '', 0)

BACKTRACE

FILE: (not given by php)
LINE: (not given by php)
CALL: msg_handler()

FILE: [ROOT]/includes/db/dbal.php
LINE: 757
CALL: trigger_error()

FILE: [ROOT]/includes/db/mysql.php
LINE: 175
CALL: dbal->sql_error()

FILE: [ROOT]/includes/functions.php
LINE: 3398
CALL: dbal_mysql->sql_query()

FILE: [ROOT]/includes/functions.php
LINE: 3025
CALL: add_log()

FILE: [ROOT]/adm/index.php
LINE: 33
CALL: login_box()

Was könnte denn das bedeuten?

Gruß, SG

So Leute, für alle die auch dieses Problem haben...
Die Lösung hab ich gefunden und es hat funktioniert.

Ändere mal das Feld "log_data" in der Tabelle "phpbb_log" in ein BLOB-Feld um.

Wenn jetzt von den Profis noch jemand sagen könnte, warum es überhaupt nötig war diese Veränderung vorzunehmen? Oder ob es eine andere Lösung gibt.
Das Board war neu installiert und außer dem Style war nichts groß geändert...

Gruß, SG

Gibts jemand der weiß, was hier schief gelaufen war?

Gruß, SG

Keine Ahnung, was da genau schief gelaufen ist, aber die Änderung/Anpassung, die Du umgesetzt hast, hat mit dem Fehler als solches nichts zu tun.

Duplicate entry '2578' for key 'PRIMARY' [1062]

Bedeutet, daß die Zahl 2578 als PRIMARY KEY schon vorhanden war und somit nicht nocheinmal eingepflegt werden konnte, weil dieser UNIQUE ist.
Der Primary key wurde für die Spalte log_id gesetzt und wird mittels AUTOINCREMENT immer weiter hoch gezählt. Das passiert automatisch. Du hast sicher gesehen, daß die SQL Query garkeine Zahl 2578 enthalten hat, weil log_id automatisch hochgezählt wird.

Kannst ja mal eine Blick auf die Indizes der Tabelle phpbb_log werfen.

Generell umgehen kannst Du solch eine Problematik mit INSERT IGNORE oder ON DUPLICATE KEY UPDATE. (<<== G00gle das mal , dann bekommst Du noch einen ganzen Haufen an Infos.) [Aber so sind die Scripte nicht ausgelegt.]

Normalerweise kannst Du BLOB nicht zum Primary Key machen; falls es doch geklappt haben sollte, kannst Du zu 99,99% davon ausgehen, daß irgendwo Daten "unterschlagen" werden (also seitens des MySQL Servers). Das nur am Rande.

Oh danke für deine Antwort!

Ich habe jetzt mal das Feld log_data wieder auf Mediumint gesetzt, und da kommt wieder der Fehler...

Sollte ich vielleicht mal in irgendwelchen Tabellen was löschen? die Keys vielleicht? So das es von vorn beginnt?

Normalerweise kannst Du BLOB nicht zum Primary Key machen; falls es doch geklappt haben sollte, kannst Du zu 99,99% davon ausgehen, daß irgendwo Daten "unterschlagen" werden (also seitens des MySQL Servers). Das nur am Rande.

Was meinst du damit? Ich kann doch in meinen Tabellen ändern was ich will, oder hab ich jetzt einen Denkfehler? Und wie Daten unterschlagen?
Bei meinem Provider gibts die Möglichkeit, eine abgespeckte PHP-Version zu benutzen. Kann es daran liegen? Aber das hier hat ja nix mit php zu tun oder?

Achso, der Fehler war auf getreten, als ich mit zwei Benutzern gleichzeitig im Forum war, weil ich was am Forum gebastelt hab und mit dem Test-Account dann immer nach geschaut hab. Das ist wohl das System mit seinen Keys durcheinander gekommen...

EDIT: Kann es sein das es daran liegt, das ich mysql5 verwende? Glaub sowas hab ich auf grad auf einer Seite gelesen...

Nimm mal das KB:stk und lasse die DB checken.
An MySQL 5 sollte es nicht liegen.

Ansonsten kannst Du auch gern die phpbb_log Tabelle löschen und neu erstellen, indem Du diesen Befehl im KB:phpmyadmin (KB:pma_faq)) ausführst:

• Code: Alles auswählen

  DROP TABLE IF EXISTS phpbb_log;
  CREATE TABLE IF NOT EXISTS phpbb_log (
    log_id mediumint(8) unsigned NOT NULL AUTO_INCREMENT,
    log_type tinyint(4) NOT NULL DEFAULT '0',
    user_id mediumint(8) unsigned NOT NULL DEFAULT '0',
    forum_id mediumint(8) unsigned NOT NULL DEFAULT '0',
    topic_id mediumint(8) unsigned NOT NULL DEFAULT '0',
    reportee_id mediumint(8) unsigned NOT NULL DEFAULT '0',
    log_ip varchar(40) COLLATE utf8_bin NOT NULL DEFAULT '',
    log_time int(11) unsigned NOT NULL DEFAULT '0',
    log_operation text COLLATE utf8_bin NOT NULL,
    log_data mediumtext COLLATE utf8_bin NOT NULL,
    album_id mediumint(8) unsigned NOT NULL DEFAULT '0',
    image_id mediumint(8) unsigned NOT NULL DEFAULT '0',
    PRIMARY KEY (log_id),
    KEY log_type (log_type),
    KEY forum_id (forum_id),
    KEY topic_id (topic_id),
    KEY reportee_id (reportee_id),
    KEY user_id (user_id)
  ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=1;

Miriam, das war die Lösung!!! Vielen vielen dank, denn mit dem zurüsetzen der phpbb_log war der Fehler weg!

Was mir aufgefallen war, ist das die phpbb_log nun als utf8_bin und InnoDB erstellt wurde.
Meine anderen Tabellen, haben alle utf8_bin und MyISAM. War das vielleicht der Fehler?

Eigentlich wollte ich auch alles als utf8_general_ci haben, aber wie ich gesehen hab ist alles utf8_bin...
Sollte ich die Kollation ändern, oder den Typ?

Und wenn, kann ich einfach den Typ und Kollation in der Tabelle ändern und alles ist gut, oder geht das nicht so einfach?

Oder sollte ich meine Tabellen so lassen wie sie sind und die phpbb_log nochmal neu erstellen, aber als MyISAM?

Wenn Du InnoDB nehmen kannst, nimm es anstatt MyISAM. Die Kollation bestimmt die Sortierreihenfolge (nach dem Alphbet).

Lies zum Thema MyISAM vs. InnoDB hier. Zum Thema Zeichensatz/Kollation hier

Ok, les ich mir durch... Danke für die Links!

Ich stell mir grad die Frage, was passiert, wenn der Zähler wieder bei 2578 angelangt ist? Ist dann nicht die gleiche Situation?
Sollt man die phpbb_log vielleicht mit einer Startzahl, z.B. 5000 starten?