Suche

[AlternativeComputing]

Im Setup, beim Update 2014-03-19 wandelt er die Spalte in den Reviews nicht um:

Code Auswählen Erweitern



ERR: Data truncated for column 'date' at row 1
in:  ALTER TABLE `mxaa5136_reviews` CHANGE `title` `title` varchar(80) NOT NULL default '', CHANGE `text` `text` text NULL, CHANGE `reviewer` `reviewer` varchar(25) NOT NULL default '', CHANGE `rlanguage` `rlanguage` varchar(40) NOT NULL default '', CHANGE `id` `id` INT(11) NOT NULL auto_increment, CHANGE `date` `date` INT(11) NOT NULL default '0', CHANGE `score` `score` tinyint(2) NOT NULL default '0', CHANGE `cover` `cover` text, CHANGE `url` `url` varchar(255), CHANGE `url_title` `url_title` varchar(80), CHANGE `hits` `hits` INT(7) NOT NULL default '0'
ERR: Data truncated for column 'date' at row 1
in:  ALTER TABLE `mxaa5136_reviews_comments` CHANGE `username` `username` varchar(25) NOT NULL default '', CHANGE `comments` `comments` text NULL, CHANGE `cid` `cid` INT(11) NOT NULL AUTO_INCREMENT, CHANGE `rid` `rid` int(11) NOT NULL default '0', CHANGE `date` `date` INT(11) NOT NULL default '0', CHANGE `score` `score` tinyint(2) NOT NULL default '0'



Das liegt daran, das das Feld Datum mit verschiedenen Werten durch verschiedene Updates befüllt wurden.

Siehe Bild.

[AlternativeComputing]

OK, das händische Umrechnen vom Datumsformat in UNIX-Timestamp Format behebt den Fehler in den 2 Tabellen.
Dieses Behebt auch das Datumsproblem von ganz alten Updates auf PMX 2.0 BETA.

[Olaf / TerraProject]

gib mal genau an, welche Tabellen und welchen Code du benutzt hast, dann lässt sich das vielleicht schon im Setup mit aufnehmen....

[AlternativeComputing]

Die beiden Tabellen sind in der Fehlermeldung:

prefix_reviews & prefix_reviews_comments

Zum umrechnen hab ich diese Seite benutzt:

http://www.aritso.net/aritso-tools/timestampconverter

[Andi]

Moin

das Feld war früher in den beiden Tabellen als varchar definiert, was allein ja schon Schwachsinn ist. Es wurden aber zumindest seit pragmaMx 0.1.10 (weiter hab ich nicht geguggt) immer nur Integer Werte eingetragen. Also dürfte die Umstellung des Feldes auf int(11) normalerweise keine Probleme bereiten.

Wie bei dir jetzt diese beiden Datensätze mit Datumsformat da rein kommen ist ungewiss. Das Datum (Jahr 2002) deutet aber irgendwie darauf hin, dass das von einer nuke-Version her reingerutscht ist.

Die Daten müssten früher schon falsch angezeigt worden sein.
Fraglich ist, ob es sich lohnt, diesen Sonderfall im Setup zu berücksichtigen...



EDIT:
gerade geguggt: pragmaMx 0.1.0
Reviews Modul, index.php, Dateidatum vom 19.03.2005,
auch dort schon Integer...

Code Auswählen Erweitern

$date =  (empty($date))  ? time() : intval($date);


EDIT 2:
und noch älter:
// $Id: index.php,v 20.1 2003/08/26 01:31:37 EllselAn Exp $
/* vkpMx 2.0  Content Management System                               */

auch dort:

Code Auswählen Erweitern

$date = time();

[AlternativeComputing]

Moin Andi,

Ja das war ein Update von einer Asbachuralt Version, das Problem werden aber einige bekommen.
Ich alleine hab ja schon 1 altes VKP und ein PMX 0.1.9 (?!?) , für Kunden, auf die 1.12.3 updaten müßen.

Sprich, wenn noch so alte Versionen auf irgendwelchen Webspaces liegen, könnten noch mehr dieses Problem bekommen.

Die Datenbank auf dem Bild ist ein Kundenbackup, welches ich nun zum Coden benutze, da es die nötigen Datensätze z.B. im Modul Reviews enthält.

Dadurch sind mir diese Probleme ja auch erst aufgefallen.

Das heißt, es muß schon beim Update von VKP auf die ersten PMX Versionen zu diesen Fehler gekommen sein, da der letzte Eintrag vor meinen Tests (id 9 auf dem Bild) schon als Unix-Timestamp abgespeichert wurde.
Ab Id 9 wurde schon ein PMX eingesetzt.

[Andi]

Hehe, habs gefunden, es kommt von phpNuke bzw. cPortal, dort ist das Feld, eigentlich korrekt als date definiert und die Daten werden auch so eingetragen.
Betrifft also alle, die irgendwann mal von nuke oder cPortal gewechselt haben.

Werde das also im Setup berücksichtigen

Update kommt...

[Andi]

So, ist angepasst....

jetzt werden die Daten im Datumsfeld geprüft und ggf. konvertiert, bevor der Feldtyp geändert wird.
Denke das müsste so funktionieren

Anbei mal die geänderte modules/Reviews/core/Install.tabledef.php zum testen.
Einfach die Datei ersetzen und dann das Setup nochmal als Update laufen lassen.

[AlternativeComputing]

OK, werde das dann mit einen Backup machen müßen.