Everything else is going just fine with the upgrade except the end result
when I upgrade the schema I get various errors like:
ERROR 1064 (42000) at line 131: You have an error in your SQL syntax;
check the manual that corresponds to your MySQL server version for the
right syntax to use near âCHARACTER SET utf8 NULL DEFAULT NULLâ at line 1
whole query:
ALTER TABLE Templates MODIFY Content BLOB CHARACTER SET utf8 NULL
DEFAULT NULL;
I donât see anything wrong with that line.
also thereâs an error displaying in every page:
The server encountered an internal error or misconfiguration and was
unable to complete your request.
etcâŚ
the error in error log is:
Canât locate object method âCleanSlateâ via package
"RT::Action::SendEmail" at
/opt/rt38/bin/âŚ/lib/RT/Interface/Web/Handler.pm line 213.\n, referer:
http://âŚ
ALTER TABLE Templates MODIFY Content BLOB CHARACTER SET utf8 NULL
DEFAULT NULL;
I donât see anything wrong with that line.
Panu -
Donât know about your other problem, but I ran into this SQL burp in
four or five different tables while going from 3.6.0 to 3.8.1rc5. MySQL
doesnât like the CHARACTER SET directive for a field of type BLOB. These
lines should probably be changed to specify TEXT instead of BLOB (or you
could remove the âCHARACTER SET utf8â directive if you know the fields
in question are used to store binary data instead of text.)
Looking at my database, Templates.Content is definitely TEXT.
Oh, and one other thing to watch out for -- the sql.queries file
that I got out of running âetc/upgrade/schema.mysql-4.0-4.1.plâ
contained some destructive transforms that I had to change. Several
multi-character fields were temporarily transformed into type CHAR,
which truncated them to a single character. Check your sql.queries file
(e.g. 'grep " CHAR " sql.queries) and make sure youâre not hitting the
same thing; in my case, one of the fields that was thus truncated was in
fact this same Templates.Content field. RTâs templates donât work so
good when they consist of only one character.
(And of course, you should reload the pristine 3.6.1 database
snapshot and start all over again after editing the sql.queries file.
But you knew that.
Cheers,
Ole
/Ole Craig
Security Engineer
Team lead, customer support
ocraig@stillsecure.com
303-381-3802 main support line
303-381-3824 my voicemail
303-381-3880 fax
www.stillsecure.comOn Tue, 2008-08-19 at 17:29 +0200, panu@colorplaza.com wrote:
ALTER TABLE Templates MODIFY Content BLOB CHARACTER SET utf8 NULL
DEFAULT NULL;
ALTER TABLE Templates MODIFY Content BLOB CHARACTER SET utf8 NULL
DEFAULT NULL;
I donât see anything wrong with that line.
Panu -
Donât know about your other problem, but I ran into this SQL burp in
four or five different tables while going from 3.6.0 to 3.8.1rc5. MySQL
doesnât like the CHARACTER SET directive for a field of type BLOB. These
lines should probably be changed to specify TEXT instead of BLOB (or you
could remove the âCHARACTER SET utf8â directive if you know the fields
in question are used to store binary data instead of text.)
Looking at my database, Templates.Content is definitely TEXT.
Oh, and one other thing to watch out for -- the sql.queries file
that I got out of running âetc/upgrade/schema.mysql-4.0-4.1.plâ
contained some destructive transforms that I had to change. Several
multi-character fields were temporarily transformed into type CHAR,
which truncated them to a single character. Check your sql.queries file
(e.g. 'grep " CHAR " sql.queries) and make sure youâre not hitting the
same thing; in my case, one of the fields that was thus truncated was in
fact this same Templates.Content field. RTâs templates donât work so
good when they consist of only one character.
Ole,
thanks a lot, I should have paid more attention to that. I for some
reason mixed up TEXT and CHAR. As the fields the queries wanted to
convert to blob were already blob I just deleted those rows and I now
have probably? a properly upgraded DB. (yes I restored an old dump first
I still have various problems, the cleanslate problem still appear in
the logs with various pages. For example:
Canât locate object method âCleanSlateâ via package
âRT::Action::SendEmailâ at
/opt/rt38/bin/âŚ/lib/RT/Interface/Web/Handler.pm line 213.\n, referer: http://xxx.yyy.com/Search/Simple.html
I also get internal server error with simple search. And for example
âhomepageâ has:
RT::ACLEquivalenceObjects Unimplemented in RT::Principal.
(/opt/rt38/bin/âŚ/lib/RT/Principal_Overlay.pm line 327) and I canât see
any of my tickets.
Forwarded to rt3.fsck.com where itâs now #12278. Will be fixed in 3.8.2On Wed, Aug 20, 2008 at 3:24 AM, Ole Craig ocraig@stillsecure.com wrote:
On Tue, 2008-08-19 at 17:29 +0200, panu@colorplaza.com wrote:
ALTER TABLE Templates MODIFY Content BLOB CHARACTER SET utf8 NULL
DEFAULT NULL;
I donât see anything wrong with that line.
Panu -
Donât know about your other problem, but I ran into this SQL burp in
four or five different tables while going from 3.6.0 to 3.8.1rc5. MySQL
doesnât like the CHARACTER SET directive for a field of type BLOB. These
lines should probably be changed to specify TEXT instead of BLOB (or you
could remove the âCHARACTER SET utf8â directive if you know the fields
in question are used to store binary data instead of text.)
Looking at my database, Templates.Content is definitely TEXT.
Oh, and one other thing to watch out for â the sql.queries file
that I got out of running âetc/upgrade/schema.mysql-4.0-4.1.plâ
contained some destructive transforms that I had to change. Several
multi-character fields were temporarily transformed into type CHAR,
which truncated them to a single character. Check your sql.queries file
(e.g. 'grep " CHAR " sql.queries) and make sure youâre not hitting the
same thing; in my case, one of the fields that was thus truncated was in
fact this same Templates.Content field. RTâs templates donât work so
good when they consist of only one character.
(And of course, you should reload the pristine 3.6.1 database
snapshot and start all over again after editing the sql.queries file.
But you knew that.
Cheers,
Ole
/Ole Craig
Security Engineer
Team lead, customer support
ocraig@stillsecure.com
303-381-3802 main support line
303-381-3824 my voicemail
303-381-3880 fax
Apache+mod_perl with two RTs in different virtual hosts?On Wed, Aug 20, 2008 at 2:03 PM, panu@colorplaza.com wrote:
ALTER TABLE Templates MODIFY Content BLOB CHARACTER SET utf8 NULL
DEFAULT NULL;
I donât see anything wrong with that line.
Panu -
Donât know about your other problem, but I ran into this SQL burp in
four or five different tables while going from 3.6.0 to 3.8.1rc5. MySQL
doesnât like the CHARACTER SET directive for a field of type BLOB. These
lines should probably be changed to specify TEXT instead of BLOB (or you
could remove the âCHARACTER SET utf8â directive if you know the fields
in question are used to store binary data instead of text.)
Looking at my database, Templates.Content is definitely TEXT.
Oh, and one other thing to watch out for -- the sql.queries file
that I got out of running âetc/upgrade/schema.mysql-4.0-4.1.plâ
contained some destructive transforms that I had to change. Several
multi-character fields were temporarily transformed into type CHAR,
which truncated them to a single character. Check your sql.queries file
(e.g. 'grep " CHAR " sql.queries) and make sure youâre not hitting the
same thing; in my case, one of the fields that was thus truncated was in
fact this same Templates.Content field. RTâs templates donât work so
good when they consist of only one character.
Ole,
thanks a lot, I should have paid more attention to that. I for some
reason mixed up TEXT and CHAR. As the fields the queries wanted to
convert to blob were already blob I just deleted those rows and I now
have probably? a properly upgraded DB. (yes I restored an old dump first
I still have various problems, the cleanslate problem still appear in
the logs with various pages. For example:
Canât locate object method âCleanSlateâ via package
âRT::Action::SendEmailâ at
/opt/rt38/bin/âŚ/lib/RT/Interface/Web/Handler.pm line 213.\n, referer: http://xxx.yyy.com/Search/Simple.html
I also get internal server error with simple search. And for example
âhomepageâ has:
RT::ACLEquivalenceObjects Unimplemented in RT::Principal.
(/opt/rt38/bin/âŚ/lib/RT/Principal_Overlay.pm line 327) and I canât see
any of my tickets.
The 3.8.1 upgrade went well. resolved the auth issues okay.
Now however, when I attach an .xls file, the file comes back
corrupted, or unreadable as an .xls file. This worked okay
on 3.6.1. Perhaps Iâve done something wrong?
read UPGRADING.mysqlOn Fri, Aug 22, 2008 at 9:43 PM, Chip Mefford cmefford@eruditium.org wrote:
The 3.8.1 upgrade went well. resolved the auth issues okay.
Now however, when I attach an .xls file, the file comes back
corrupted, or unreadable as an .xls file. This worked okay
on 3.6.1. Perhaps Iâve done something wrong?
:ACLEquivalenceObjects Unimplemented in RT::Principal.