[Fixed] UTF-8
Page: 1
Recent posts in this topic
We had a little chat over e-mail about this, what's the status with UTF-8 support now?
I took some time to glance through your code, I suppose the "SET NAMES 'utf8';" that is supposed to be sent after connecting to the database is still not implemented (I suppose this should be in MysqlDBAdapter.class.php?)? Could you please hurry with this, cause as the time passes by, I'll have more and more lines to "transcode" in the database, from latin1 to utf-8 :)
I took some time to glance through your code, I suppose the "SET NAMES 'utf8';" that is supposed to be sent after connecting to the database is still not implemented (I suppose this should be in MysqlDBAdapter.class.php?)? Could you please hurry with this, cause as the time passes by, I'll have more and more lines to "transcode" in the database, from latin1 to utf-8 :)
Ilija Studen
on Jul 5. 2006. 1:21 pm
Quick fix:
1. open config/config.php and add new constant: define('DB_CHARSET', 'utf8');
2. open init.php and scroll to try-catch block where we connect to database and change it to look like this:
Only difference is that we execute SET NAMES if we have DB_CHARSET config set.
Also, I don't know how fields are imported at your database but make sure that you use utf8_general_ci collation for VARCHAR and text fields. Or you did that already? :)
1. open config/config.php and add new constant: define('DB_CHARSET', 'utf8');
2. open init.php and scroll to try-catch block where we connect to database and change it to look like this:
// Connect to database...
try {
DB::connect(DB_ADAPTER, array(
'host' => DB_HOST,
'user' => DB_USER,
'pass' => DB_PASS,
'name' => DB_NAME,
'persist' => DB_PERSIST
)); // connect
if(defined('DB_CHARSET') && trim(DB_CHARSET)) $res = DB::execute("SET NAMES " . DB::escape(DB_CHARSET));
} catch(Exception $e) {
if(Env::isDebugging()) {
Env::dumpError($e);
} else {
die('Failed to connect to database. Reason: ' . $e->getMessage());
} // if
} // tryOnly difference is that we execute SET NAMES if we have DB_CHARSET config set.
Also, I don't know how fields are imported at your database but make sure that you use utf8_general_ci collation for VARCHAR and text fields. Or you did that already? :)
activeCollab team member
Ilija Studen
on Jul 5. 2006. 1:24 pm
And one discussion here: do you think that it's smart to limit usage of activeCollab only for MySQL 4.1? Or to hack installer so it can create import construction in older versions of MySQL?
activeCollab team member
Ofcourse I did :) Actually it was like that when I installed activeCollab because the database I installed it in had utf8_general_ci set already :)
Sorry, haven't seen your second post. I don't see a problem in adding a couple of lines of code to the installer not to use the collation's attribute during tables creation.
On the other hand, I don't think you're gonna find a web hosting that offers PHP5 but still runs on MySQL <4.1. But then, I maybe wrong.
p.s. Not to mention that even Debian offers MySQL 4.1 in their official repository, I believe that says enough :)
On the other hand, I don't think you're gonna find a web hosting that offers PHP5 but still runs on MySQL <4.1. But then, I maybe wrong.
p.s. Not to mention that even Debian offers MySQL 4.1 in their official repository, I believe that says enough :)
Ilija Studen
on Jul 5. 2006. 2:25 pm
gog:On the other hand, I don't think you're gonna find a web hosting that offers PHP5 but still runs on MySQL <4.1. But then, I maybe wrong.
p.s. Not to mention that even Debian offers MySQL 4.1 in their official repository, I believe that says enough :)
Exactly! MySQL 4.1 is stable and you can say that its default for PHP5 hosting. I’ve deployed few PHP5 scripts on various hosting providers and all of them had MySQL 4.1
activeCollab team member
Topic is locked. If you have something important to say about issues discussed on this page please write at hi@a51dev.com.
