Problem upgrading from 3.6.1 to 3.8.1

Everything else is going just fine with the upgrade except the end result :slight_smile:

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://…

are these 2 errors related.

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. :slight_smile:

(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. :slight_smile:

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;

I don’t see anything wrong with that line.

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. :slight_smile:

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 :slight_smile:

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::ticket::ACLEquivalenceObjects Unimplemented in RT::Principal.
(/opt/rt38/bin/…/lib/RT/Principal_Overlay.pm line 327) and I can’t see
any of my tickets.

Same kind of error appears on almost all pages.

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. :slight_smile:

(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. :slight_smile:

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

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.


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

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. :slight_smile:

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 :slight_smile:

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::ticket::ACLEquivalenceObjects Unimplemented in RT::Principal.
(/opt/rt38/bin/…/lib/RT/Principal_Overlay.pm line 327) and I can’t see
any of my tickets.

Same kind of error appears on almost all pages.


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.

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?

No errors are generated when attaching a file.

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?

No errors are generated when attaching a file.


http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Best regards, Ruslan.