Closed Bug 328013 Opened 19 years ago Closed 19 years ago

UTF-8 connect to mysql

Categories

(Bugzilla :: Database, defect)

2.21
x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 304550

People

(Reporter: bugzilla.10.deep125, Unassigned)

Details

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\DB.pm 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 IIS C:\Inetpub\BUGZIL~1.1>perl checksetup.pl 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: http://landfill.bugzilla.org/ppm/ You can add the repository with the following command: ppm rep add bugzilla http://landfill.bugzilla.org/ppm/ 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 http://www.imagemagick.org, 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)
(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+
Version: unspecified → 2.21
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.
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?
*** This bug has been marked as a duplicate of 304550 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.