ERR: Data truncated

Begonnen von AlternativeComputing, 19 März 2014, 08:30:43

⏪ vorheriges - nächstes ⏩

0 Mitglieder und 1 Gast betrachten dieses Thema.

AlternativeComputing

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



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.
MfG

Peter

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.
MfG

Peter

Olaf

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

Olaf

Kein Support über PN, Mail etc.!
Bitte die Fragen im Forum stellen, nur so helfen die Antworten auch den anderen Usern.
Bitte auch die Boardsuche nicht vergessen, oft ist genau dein Problem schon an anderer Stelle gelöst worden!

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
MfG

Peter

Andi

#4
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...

$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: $date = time();
schön´s Grüssle, Andi

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.

MfG

Peter

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...
schön´s Grüssle, Andi

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.
schön´s Grüssle, Andi

AlternativeComputing

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

Peter