The problem is that there are some non-english characters in the notes and that the 'body' column was in latin1. I changed it to utf8 and everything works now.

Hello, striker69
I have the same problem. What exactly do you change?
In my case the problem appears when issue depends on another issue, and in e-mail text I see (russian) "Depends on 0001064 Some russian tex<?>...\n"
But on View Issue page I see normal text without "<?>" (black diamond with question sign inside)

OK, the problem actually in number of bytes left in Summary field of related issues during email building.
When I add an extra space between words: "0001064 Some russian text", the email was successfully send. So there is some cutting function, that cut UTF8 string incorrectly. Could someone help to fix this??? Please!!!!

OK, some workaround found (may be need more work).
In relationship_api.php add a function (I took it from http://ru2.php.net/manual/en/function.substr.php)

function utf8_substr($str,$from,$len){

utf8 substr

www.yeap.lv

return preg_replace('#^(?:[\x00-\x7F]|[\xC0-\xFF][\x80-\xBF]+){0,'.$from.'}'.
'((?:[\x00-\x7F]|[\xC0-\xFF][\x80-\xBF]+){0,'.$len.'}).*#s',
'$1',$str);
}

and change a line in function relationship_get_details:

$t_relationship_info_text .= utf8_substr( $t_bug->summary, 0, $t_summary_wrap_at - 3 ) . '...';

That works for me.

We have exactly the same problem.
Thank you for the workaround 'konstbel', we will try this and let you know if it works as expected.

We had another issue:
In the description, some has added the special chars
U+02DD, U+05F4
(like double lower comas and double high comas)
With this special chars even the above code doesn't help. Do we have to expand it with additional char-ranges?

Unfortunately, I do not know, I'm not specialist in PHP. Try to do that, if you know how, and write here the solution, if you find.
I think one of the ways could be to replace your double commas with (") chars.

Some news on this point? Today we found another char not working: Alt+0133
Do we have no way to "clear" the $c_body before inserting in the 'mantis_email_table.body'-field?

Could you please have a look at the \core\email_queue_api.php?

I found the position BEFORE the failing INSERT INTO-Statement:
$c_metadata = serialize( $t_email_data->metadata );

If the field $c_metadata contains some "strange" characters like the mentioned above or like this: … (only 1 char, not 3 points!!) then we get a "Application error 0000401" and "#1406: Data too long for column 'body'".

How can we CLEAN this field before saving it to the DB?
Maybe something like 'mysql_real_escape_string'?
Any other ideas?

I have the similar problem from time to time since we have upgraded from 1.0.6 to 1.1.2. There are a lot of APPLICATION WARNING 300 and then APPLICATION ERROR 401:

Database query failed. Error received from database was #1406: Data too long for column 'body' at row 1... Request is INSERT INTO mantis_email_table(...

Sometimes it happens when I close an issue with assigning the version number in which it was resolved, and in this case the version change does not go to the database indeed, so I need to check it and do it again.

It will be great, if possible, to have some feedback from Mantis team about this issue to be sure that the future 1.2... stable release will be free of this problem.

Observed error message when attempting to change status on an issue:

APPLICATION ERROR 0000401
Database query failed. Error received from database was #1406: Data too long for column 'body' at row 1 for the query: INSERT INTO mantis_email_table
( email,
subject,
body, ...

This is with Mantis:
MantisBT Version 1.2.0rc2
Schema Version 179

This database was originally at version 1.1.2a03 -> 1.2.0a03 -> 1.2.0rc2

The problem appears to be that the database has mantis_email_table.body as TEXT when the code is assuming type LONGTEXT. I noticed that the schema upgrade logic does not appear to upgrade the body column. Some of issues have long notes....

It seems that an appropriately fashioned xlter command could resolve this issue. Could someone on the development team comment on this issue?

I changed the body character type from latin 1 to utf8 just in case that is the problem. Some notes get pasted from other tools....

I can confirm that this error is closely related to email feature. When I turn off emailing, no such error happens.

We are resolving this issue as "no change required", because it was reported against an old version of MantisBT which is no longer supported.

We recommend that you upgrade to the latest stable version [1]; if after doing so the problem still exists, do not hesitate to reopen the issue.

[1] https://sourceforge.net/projects/mantisbt/files/mantis-stable/

Wow, what kind of a solution!

Waiting more then 4 years (since the first entry for this bug) and then "resolve" this issue because of "an old version which is no longer supported"?

Never seen before - but to be honest: I'm lucky. I've found another ticketing solution 3 years ago.

@PatPowerMan,

This issue is not reproducible in the current version of Mantis, hence my closure of the bug report and recommendation to upgrade.

I'm glad to hear you are happily using another software. That said, please go back to where you came from, and don't bother posting such useless and non-constructive comments here again.