can't
interpret it just trashes you data and truncates it rather than failing
and throwing an error.
It is easy to workaround by using LONGBLOB rather than LONGTEXT or never
store 8BITMIME encoded email in a longtext field.
It is related to this, http://bugs.mysql.com/bug.php?id=18908, but not
exac
Hi.
Look at the output of
show variables like '%character_set%';
show variables like '%collat%';
show create table 'your_table';
Are all character_sets and collations the same?
Keith Morris <[EMAIL PROTECTED]> wrote:
> We are in the process of upgrading our installation of MySQ
We are in the process of upgrading our installation of MySQL 4.0 to
4.1.7 and are having an issue in our testing.
We have an internal CMS that was developed with MySQL 4.0 and PHP. We
very often insert Text with extended characters (trademark, copyright,
registered, etc) into latin1 tables with
Richard Clarke wrote:
>
> I thought truncates were supposed to be really fast. I don't really notice
> any difference in speed between a truncate query and a delete query. What is
> actually involved in a truncate. The docs says its faster because a drop and
> recreate oc
I thought truncates were supposed to be really fast. I don't really notice
any difference in speed between a truncate query and a delete query. What is
actually involved in a truncate. The docs says its faster because a drop and
recreate occurs but how is this actually faster.
