Hi Stan,
have you noticed the solution to the "Umlaut" problem, I posted in the support thread?
If not, here it is again:
One of our support guys found the reason for this strange behaviour. It's a piece of code in lmfunctions.php.
This is the original version:
$version = GetmySQLFullVersion();
if ( $version[0] >= 5 && $version[1] >= 2 && $version[2] >= 3 ) { @mysql_set_charset( "utf8", $mysql_link ); }
$mysql_charset = @mysql_client_encoding( $mysql_link ); // Success?
return true;
From MySQL Version 5.2.3 on the data base connection was set to UTF-8, but it should not refer to the MySQL version but to the PHP-Version, as the function mysql_client_encoding exists in PHP since version 5.2.3.
We have replaced this bit of code by:
if (function_exists("mysql_set_charset"))
@mysql_set_charset( "utf8", $mysql_link );
$mysql_charset = @mysql_client_encoding( $mysql_link ); // Success?
If the function exists, it is used, otherwise ignored.
In our case the SQL-Server got UTF-8 code but handled it as latin1 converting it a second time to UTF-8. This caused the problem.
Now everything is running fine again.
Regards
Prodrive
have you noticed the solution to the "Umlaut" problem, I posted in the support thread?
If not, here it is again:
One of our support guys found the reason for this strange behaviour. It's a piece of code in lmfunctions.php.
This is the original version:
$version = GetmySQLFullVersion();
if ( $version[0] >= 5 && $version[1] >= 2 && $version[2] >= 3 ) { @mysql_set_charset( "utf8", $mysql_link ); }
$mysql_charset = @mysql_client_encoding( $mysql_link ); // Success?
return true;
From MySQL Version 5.2.3 on the data base connection was set to UTF-8, but it should not refer to the MySQL version but to the PHP-Version, as the function mysql_client_encoding exists in PHP since version 5.2.3.
We have replaced this bit of code by:
if (function_exists("mysql_set_charset"))
@mysql_set_charset( "utf8", $mysql_link );
$mysql_charset = @mysql_client_encoding( $mysql_link ); // Success?
If the function exists, it is used, otherwise ignored.
In our case the SQL-Server got UTF-8 code but handled it as latin1 converting it a second time to UTF-8. This caused the problem.
Now everything is running fine again.
Regards
Prodrive