CONTENIDO Forum

Guten Abend

Ich verwende Contenido 4.4.5
und MySQL 4.1.10a

Seit dem letzten MySQL-Update auf 4.1
wird die Statistik zwar geführt, aber nicht mehr archiviert am Monatsende.
Das Error-Log weisst einen Syntax-Fehler für die Tabelle con_stats_archvie aus:

[23-May-2005 22:04:37] MySQL error 1064: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '22:03:28)' at line 11
INSERT INTO
con_stat_archive
( idstatarch, archived, idcatart, idlang, idclient, visited, visitdate )
VALUES
(32113,
200504,
889,
5,
4,
0,
2005-05-23 22:03:28)

Ich denke, das hat mit der Timestamp-Funktion zu tun, finde aber nicht heraus, wo der Fehler im File includes/functions.stat.php liegt:

while ($db->next_record())
{
$insertSQL = "INSERT INTO
".$cfg["tab"]["stat_archive"]."
( idstatarch, archived, idcatart, idlang, idclient, visited, visitdate )
VALUES
(".$db2->nextid($cfg["tab"]["stat_archive"]).",
".$yearmonth.",
".$db->f(0).",
".$db->f(1).",
".$db->f(2).",
".$db->f(3).",
".$db->f(4).")";

$db2->query($insertSQL);
}

Kennt sich da jemand aus oder kennt jemand eine Lösung, wie ich die Statstik wieder achriviert bekomme?

hmm... ist der server lokal oder im netz ?

einen verdacht hab ich ja, habe aber erst in ca 14 tagen die möglichkeit das auf einer mysql 4.1 umgebung zu testen...

etwas ähnliches wurde schon mal im forum besprochen... mal schauen ob ich das noch finde...
soweit ich das noch weiss wurde dort einmal der letzte wert (also das datum) von quotes (') umschlossen...

emergence hat geschrieben:soweit ich das noch weiss wurde dort einmal der letzte wert (also das datum) von quotes (') umschlossen...

Ich kann mich an die Diskussion nicht erinnern, aber was du sagst ist logisch, weil visitdate aus Datum und Uhrzeit mit Leerzeichen dazwischen besteht, also muss das als String behandelt werden (auch sonst wird das Datum eigentlich in Anfuehrungszeichen angegeben).

ähm benötigt MySQL 4.1 nicht auch die neuen MySQL-Funktionen in PHP?

Ich hatte es nie getestet, ging aber bisher davon aus, daß Contenido deshalb nicht ohne weiteres mit MySQL 4.1 läuft?

timo hat geschrieben:ähm benötigt MySQL 4.1 nicht auch die neuen MySQL-Funktionen in PHP?

Ich hatte es nie getestet, ging aber bisher davon aus, daß Contenido deshalb nicht ohne weiteres mit MySQL 4.1 läuft?

ich glaub da eher das es vielleicht etwas mit dem feldtyp timestamp zu tun hat
-> http://dev.mysql.com/doc/mysql/en/upgra ... m-4-0.html

Der SQL-Server ist lokal. Sonst läuft Contenido 4.4.5 problemlos mit MySQL 4.1.

Wenn ich den SQL-Dump mit der Funktion vergleiche, kann ich eigentlich keinen Unterschied erkennen. Darum bin ich wohl auch Marketer und nicht Programmierer geworden. Hier ist ein Auszug aus dem SQL Dump aus phpmyadmin:

CREATE TABLE `con_stat_archive` (
`idstatarch` int(10) NOT NULL default '0',
`archived` varchar(6) collate latin1_german1_ci NOT NULL default '',
`idcatart` int(10) NOT NULL default '0',
`idlang` int(10) NOT NULL default '0',
`idclient` int(10) NOT NULL default '0',
`visited` int(6) NOT NULL default '0',
`visitdate` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
PRIMARY KEY (`idstatarch`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci;

--
-- Dumping data for table `con_stat_archive`
--

INSERT INTO `con_stat_archive` VALUES (2, '200408', 50, 1, 1, 1179, '2004-09-01 16:20:23');
INSERT INTO `con_stat_archive` VALUES (3, '200408', 37, 1, 1, 280, '2004-08-31 14:05:12');...

bitte ersetze mal in der Datei functions.stat.php innerhalb der Funktion statsArchive

Code: Alles auswählen

while ($db->next_record())
    {
        $insertSQL = "INSERT INTO
                          ".$cfg["tab"]["stat_archive"]."
                          ( idstatarch, archived, idcatart, idlang, idclient, visited, visitdate)
                      VALUES
                          (".$db2->nextid($cfg["tab"]["stat_archive"]).",
                           ".$yearmonth.",
                           ".$db->f(0).",
                           ".$db->f(1).",
                           ".$db->f(2).",
                           ".$db->f(3).",
                           ".$db->f(4).")";

        $db2->query($insertSQL);
    }

durch

Code: Alles auswählen

while ($db->next_record())
    {
        $insertSQL = "INSERT INTO
                          ".$cfg["tab"]["stat_archive"]."
                          ( idstatarch, archived, idcatart, idlang, idclient, visited, visitdate)
                      VALUES
                          (".$db2->nextid($cfg["tab"]["stat_archive"]).",
                           ".$yearmonth.",
                           ".$db->f(0).",
                           ".$db->f(1).",
                           ".$db->f(2).",
                           ".$db->f(3).",
                           '".$db->f(4)."')";

        $db2->query($insertSQL);
    }

sowie

Code: Alles auswählen

        $insertSQL = "INSERT INTO
                          ".$cfg["tab"]["stat"]."
                          ( idstat, idcatart, idlang, idclient, visited )
                      VALUES (
                          ".$db2->nextid($cfg["tab"]["stat"]).",
                          ".$db->f(0).",
                          ".$db->f(2).",
                          ".$db->f(1).",
                         0)";

        $db2->query($insertSQL);

durch

Code: Alles auswählen

        $insertSQL = "INSERT INTO
                          ".$cfg["tab"]["stat"]."
                          ( idstat, idcatart, idlang, idclient, visited )
                      VALUES (
                          ".$db2->nextid($cfg["tab"]["stat"]).",
                          ".$db->f(0).",
                          ".$db->f(2).",
                          ".$db->f(1).",
                          '0000-00-00 00:00:00')";

        $db2->query($insertSQL);

Hallo Timo

Vielen Dank. Die Lösung mit den Anführungszeichen scheint zu klappen. Ich habe die .job Dateien im cronjobs-Ordner gelöscht und die Funktion move_old_stats.php manuell ausgeführt. Der Mai wurde archiviert und die bisherigen Zahlen dem Mai gutgeschrieben.

Hoffen wir, dass die Statistik wieder automatisch arichviert wird. Manchmal gab es Permission-Probleme mit den job-Dateien im Ordner Cronjobs. Mit 777 werden die Skripts nicht ausgeführt. Jetzt ist der Ordner auf 777 und die PHP-Dateien auf 755. Die job-Dateien werden mit 644 erstellt.

Vielen Dank für die Unterstützung.

alles klar, dann schließe ich hier mal

Ich hab' das hier wieder aufgemacht, sorry timo.

Du hast hier zwar die Loesung angegeben, in Contenido selbst wurde es leider aber nicht behoben (habe gerade in der neuesten 4.4.6 nachgeschaut). Ich denke, so lange die 4.4er Versionen noch angeboten werden (danke uebrigens auch fuer die schnelle Reaktion auf die Sicherheitsluecke), sollte das auch direkt in Contenido ersetzt werden. Ich durfte gerade 211 errorlog-Eintraege per Hand ueberarbeiten, um die Daten in die Statistik-Tabelle nachtraeglich eintragen zu koennen, weil die so doof waren, dass sie sich nicht mit Suchen&Ersetzen bearbeiten liessen.
Das ist zwar ein Problem der neueren MySQL-Versionen, aber die Loesung duerfte auch bei aelteren Versionen keine Probleme machen, da die Angabe des Datums, sofern es die Uhrzeit beinhaltet, in Anfuehrungszeichen "normal" ist.

Im Bugtracker ergänzt.

Gruß
HerrB

CONTENIDO Forum

SQL-Syntax Error in der Tabelle con_stats_archive

SQL-Syntax Error in der Tabelle con_stats_archive