13 years ago
11 years ago


(Reporter: bugzilla.10.deep125, Unassigned)


Windows 2000




13 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; MyIE2; .NET CLR 1.1.4322)
Build Identifier: 2.21.1+(download by CVS from 2006-02-20)

Can not get data from mysql server. 

Reproducible: Always

Steps to Reproduce:
1.Instal Bugzilla version 2.17.6
2.Make MuSql server for work with utf-8 charsets
3.Add bug in Russian Lanuage
4.Instal Bugzila version 2.21.1+
5.try read bug

Actual Results:  
Resultat is
(????? ?????)

Expected Results:  
I am resolve this problem make next change in file Bugzilla\
Old code
# instantiate the correct DB specific module
   my $dbh = $pkg_module->new($user, $pass, $host, $dbname, $port, $sock);
   return $dbh;

new code
# instantiate the correct DB specific module
   my $dbh = $pkg_module->new($user, $pass, $host, $dbname, $port, $sock);
   $dbh->do("SET SESSION character_set_connection=utf8");
   $dbh->do("SET SESSION character_set_results=utf8");
   $dbh->do("SET SESSION character_set_client=utf8");
   return $dbh;

Windows 2000Service Pack 4


Checking perl modules ...
Checking for       AppConfig (v1.52)   ok: found v1.55
Checking for             CGI (v2.93)   ok: found v3.10
Checking for    Data::Dumper (any)     ok: found v2.121_04
Checking for    Date::Format (v2.21)   ok: found v2.22
Checking for             DBI (v1.38)   ok: found v1.49
Checking for      File::Spec (v0.84)   ok: found v3.05
Checking for      File::Temp (any)     ok: found v0.16
Checking for        Template (v2.08)   ok: found v2.13
Checking for      Text::Wrap (v2001.0131) ok: found v2001.09293
Checking for    Mail::Mailer (v1.67)   ok: found v1.67
Checking for    MIME::Base64 (v3.01)   ok: found v3.05
Checking for     MIME::Tools (v5.406)  ok: found v5.411
Checking for        Storable (any)     ok: found v2.13

The following Perl modules are optional:
Checking for              GD (v1.20)   ok: found v2.16
Checking for     Chart::Base (v1.0)    ok: found v2.3
Checking for       XML::Twig (any)      not found
Checking for       GD::Graph (any)     ok: found v1.43
Checking for GD::Text::Align (any)     ok: found v1.18
Checking for     PatchReader (v0.9.4)  ok: found v0.9.5
Checking for   Image::Magick (any)      not found

All the required modules are available at:
You can add the repository with the following command:
    ppm rep add bugzilla

If you want to use the bug import/export feature to move bugs to
or from other bugzilla installations, you will need to install
 the XML::Twig module by running (as Administrator):

   ppm install XML::Twig

If you want to convert BMP image attachments to PNG to conserve
disk space, you will need to install the ImageMagick application
Available from, and the Image::Magick
Perl module by running (as Administrator):

   ppm install Image::Magick

Checking user setup ...
Removing existing compiled templates ...
Precompiling templates ...
Checking for      DBD::mysql (v2.9003) ok: found v3.0002
Checking for           MySQL (v4.0.14) ok: found v4.1.8-nt
Did you upgrade MySQL in between at all?  I notice you're using MySQL 4.1.x now, the upgrade to 4.1.x from anything earlier does lots of screwy things with character set conversions if not done properly.  (The upgrade docs strongly suggest dumping all databases before upgrading, and restoring them after the upgrade)

Comment 2

13 years ago
(In reply to comment #1)
> Did you upgrade MySQL in between at all? 

I am work in version Bugzilla 2.17.6 about 2 yers, with MySql ver 4.1 x

Upgrade only Bugzilla from 2.17.6 to 2.21.1+


13 years ago
Version: unspecified → 2.21

Comment 3

13 years ago
We need to consider whether or not we want Bugzilla to require a UTF-8 database. It may be necessary. That means upgrading would require a database dump and restore. Bugzilla 3.0 would be the perfect time for that requirement.

I have known it to cause difficulties on PostgreSQL with Unicode characters above 10,000.

Comment 4

13 years ago
I don't think it would require a dump and restore in mysql.
Mysql allows individual tables and rows to have their encodings altered.  If you change directly from latin1 to utf8, it will convert the data.  If you change first from latin1 to binary and then from binary to utf8, it does not convert.  

Is this a dupe of bug 304550?

Comment 6

13 years ago

*** This bug has been marked as a duplicate of 304550 ***
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.