Tickets :: Comment on [#9263] Problems with serialized arrays stored in a MySQL DB

* Your Email Address
* Spam protection	Enter the letters below: .___.__ . .. ..___ [__ [ __\|\/\|\ /[__ [___[_./\| \| \/ \|
Comment	> Our production horde system is running with PHP 5.2.13 with MySQL > 5.0.67 (OpenSUSE 11.1). The development system has PHP 5.3.3 and the > MySQL on the DB server is 5.1.46 (both OpenSUSE 11.3). I've created a > utf8 dumpfile of the old database with phpmyadmin, changed the > CHARSET to utf8 and imported it on the new DB server. > > If I now login to the development horde, the identities aren't > displayed at all. The reason for this is the php unserialize > function, which reports an error at offset... It complains about the > string length of "Standardidentität", which was previously 17 and now > with utf8 it is 18. In the manual of unserialize at php.net > (http://www.php.net/manual/de/function.unserialize.php#75773) there > are a couple of comments for this issue and I was able to fix to the > wrong string length for the utf8 thing with php's preg_replace > function. > > But the identities are still not displayed for those users, which > have a signature or some alias adresses, e.g. configured. There are > several occurrences of "\r\n" in my dumpfilere. If I apply my > preg_replace function on a serialized array returned by MySQL, the > result differs from applying the function to the accordant line on my > dumpfile. E.g. the strlen functions reports a string length of 495 > for my signature fetched from the database, but according to my > dumpfile, the string length of my signature is 527. This results > again in an error at offset.. reported by unserialize. > > Is there any documented way on how I could first migrate the db from > latin1 to utf8 as well as having all these serialized arrays beeing > transformed, so that they are still usable?
Attachment
Watch this ticket

Saved Queries