SQL-Syntax Error in der Tabelle con_stats_archive
SQL-Syntax Error in der Tabelle con_stats_archive
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?
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...
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...
*** make your own tools (wishlist :: thx)
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
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).emergence hat geschrieben:soweit ich das noch weiss wurde dort einmal der letzte wert (also das datum) von quotes (') umschlossen...
ich glaub da eher das es vielleicht etwas mit dem feldtyp timestamp zu tun hattimo 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?
-> http://dev.mysql.com/doc/mysql/en/upgra ... m-4-0.html
*** make your own tools (wishlist :: thx)
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');...
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');...
-
- Beiträge: 6284
- Registriert: Do 15. Mai 2003, 18:32
- Wohnort: Da findet ihr mich nie!
- Kontaktdaten:
bitte ersetze mal in der Datei functions.stat.php innerhalb der Funktion statsArchive
durch
sowie
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);
}
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);
}
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);
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.
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.
-
- Beiträge: 5478
- Registriert: Di 2. Mär 2004, 21:11
- Wohnort: Halchter, wo sonst? ;-)
- Kontaktdaten:
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.

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
Gruß
HerrB
Bitte keine unaufgeforderten PMs oder E-Mails -> use da Forum!
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net
Newsletter: V4.4.x | V4.6.0-15 (Module, Backend) | V4.6.22+
Standardartikelliste: V4.4.x | V4.6.x
http://www.contenido.org/forum/search.php | http://faq.contenido.org | http://www.communido.net