Chronik wird nicht angezeigt

  • Das hat doch nichts mit dem Aufruf von URLs zu tun. Es geht dabei um die Form der Ablage der Daten in der DB. In der Tabelle moz_places wird jeder URL nur einmal abgelegt. Redundanz an der Stelle ist nicht vorgesehen. Deine Visits, also mehrfache Aufrufe des selben URL, werden in einer anderen Tabelle abgelegt. Die ID ist nur für interne Zwecke vorgesehen und tritt gegenüber dem Nutzer nicht in Erscheinung.

  • Ah, das ist aber kompliziert gelöst. Ich denke mal, die doppelten URLs sind dadurch entstanden, dass Firefox die Tabelle lesen konnte und somit URLs jedes Mal wieder angelegt hat. Aber so wie ich das jetzt sehe, müsste die Chronik auch ohne die unbedingte Einzigartigkeit der URL funktionieren - ich mal weiterversuchen, den Unique Index von der url-Spalte zu nehmen.

  • Zitat von thorr

    auch ohne die unbedingte Einzigartigkeit der URL funktionieren - ich mal weiterversuchen, den Unique Index von der url-Spalte zu nehmen.


    Das würde ich nicht machen.
    Diese Fehlermeldung kann auch bedeuten das in dieser Tabelle ein korrupter Wert steht.

  • Ok, das würde sich auch mit dem Eingangsproblem decken, dass die Tabelle corrupt ist. Gibt es ein Hilfstool, mit dem ich herausfinden kann, ob und wo der Fehler in den ca 90000 Einträgen liegt?

  • Zitat

    Aber so wie ich das jetzt sehe, müsste die Chronik auch ohne die unbedingte Einzigartigkeit der URL funktionieren

    Das halte ich für eine gewagte Annahme. Die vorgegebenen Strukturen sind nicht aus Jux so gewählt. Welche Folgen Mehrfach-Einträge dort haben können, ist ad hoc kaum abzuschätzen. Insbesondere dient der Index auch dazu den Zugriff auf die Daten zu beschleunigen.
    Der Fehlermeldung oben nach scheint er genau solche Dubletten zu bemängeln. Daher würde ich das Datenmaterial nach solchen Vorkommen durchsuchen und dies ggf. bereinigen bevor du an den Strukturen rumpfuschst.

  • Zitat von thorr

    Gibt es ein Hilfstool, mit dem ich herausfinden kann, ob und wo der Fehler in den ca 90000 Einträgen liegt?


    Gibt es sicher, ich kenne aber keines.

    Ich kenne die Struktur nicht. Aber ich würde mal mit einem Hex-Editor in diese DB reinschauen, versuchen die Werte der Tabelle zu lokalisieren und manuell nach Auffälligkeiten suchen.

  • Noch ein Nachtrag.
    sqlite und php harmonieren gut miteinander.
    Suche doch mal nach einem Admintool das unter einem Webserver (z.b. xampp) läuft und für die adminstration von sqlite-DB gemacht ist.
    Für Mysql gibt es jede Menge Tools die auch reparieren können, vielleicht gibt es sowas auch für sqlite.

  • Ah, das ist eine Superidee - ich hatte schon überlegt, den Dump in meine MySQL-Datenbank zu importieren und mit phpMyAdmin mal draufzuschauen. Mit einem SQLite-Tool ist das aber ja noch viel praktischer - ich werd mich mal auf die Suche begeben.

    Vielen Dank auf jeden Fall schon einmal für eure geduldige Hilfe!

  • Ich habe das Dumpen der places.sqlite nachvollzogen. Nach dem Dump und dem künstlichen Einfügen einer Dublette in moz_places reproduziert dieses Vorgehen beim erneuten Einlesen deine Fehlermeldung.

  • Du verwendest doch Windows, dafür gibt es auch Perl-Interpreter. Mit dem Skript kannst du dir ggf. vorhandene URL-Dubletten aus der moz_places in deinem Dumb-File anzeigen lassen. Einfach den entsprechenden Dateinamen setzen.

  • Nachdem ich irrtümlich davon ausgegangen war, dass Perlskripte voll und ganz mit PHP vergleichbar sind und ich so vergeblich versucht habe, den frisch installierten Interpreter auf meinen Apache einzurichten (was zur besten Zeit mit einem 500-Error geendet hat), habe ich nun endlich entdeckt, wie man Perlskripte richtig aufrufen kann (über die Kommandozeile) und es funktioniert perfekt. Vielen Dank!

    Ich bin jetzt dabei, die Tabelle zu bereinigen. Mir sind dabei zwei Einträge folgender Art aufgefallen:

    SQL
    INSERT INTO "moz_places" VALUES(90639,'javascript:parent.getTag(''adscale:NTM3MDA:ad:0'');','',NULL,0,1,0,NULL,0);

    Das sieht für mich an den Stellen mit den zwei aufeinanderfolgenden, einfachen Anführungszeichen nach höchst fehlerhafter SQL-Syntax aus - oder ist das richtig so? Ich hab das jetzt erst einmal berichtigt, indem ich ein Anführungszeichen entfernt und das darauffolgende maskiert habe.

    Andere doppelte Einträge berichtige ich, indem ich ein unerhebliches Zeichen in der URL abändere, da ansonsten, denke ich, in der moz_historyvisits das Gegenstück zu einigen place_ids fehlt.

  • Zitat

    Das sieht für mich an den Stellen mit den zwei aufeinanderfolgenden, einfachen Anführungszeichen nach höchst fehlerhafter SQL-Syntax aus

    Ne das passt, siehe:
    http://www.sqlite.org/lang_expr.html

    Zitat

    A string constant is formed by enclosing the string in single quotes ('). A single quote within the string can be encoded by putting two single quotes in a row


    Gleichzeit führt mich das aber zu einem Fehler im Perl-Skript. Den Fall hatte ich nicht abgefangen.
    Folgende Zeile sollte das besser berücksichtigen:

    Code
    if ($i =~ /"moz_places" VALUES\(\d+,'(.+[^'])',/) {


    Edit: oben korrigiert

    Zitat

    Andere doppelte Einträge berichtige ich, indem ich ein unerhebliches Zeichen in der URL abändere, da ansonsten, denke ich, in der moz_historyvisits das Gegenstück zu einigen place_ids fehlt.

    Sinnvoll.

  • Das Einlesen des Dumps in die Datenbank funktioniert jetzt auf jeden Fall schon einmal und mit dem SQLite Manager lesbar ist die Tabelle auch. Nur macht Firefox immer noch Stress und leert die Chronik beim Start. Was könnte Firefox da für Probleme haben?

  • Firefox leert die Tabelle die Chronik - ich denke, so verfährt Firefox 3.5 immer, wenn die Chronik für ihn nicht lesbar ist, denn das gleiche ist vorher bei der beschädigten Tabelle passiert.