Hi,
On Sep 6, 2012, at 1:24, Daniel Convissor dani...@analysisandsolutions.com
wrote:
Hi Johannes:
On Thu, Jan 19, 2012 at 01:50:47PM +0100, Johannes Schlüter wrote:
unsigned long length
The width of the field. This corresponds to the display length,
in bytes.
Hi Johannes:
On Thu, Jan 19, 2012 at 01:50:47PM +0100, Johannes Schlüter wrote:
unsigned long length
The width of the field. This corresponds to the display length,
in bytes.
The server determines the length value before it generates the
result set,
Hi Johannes:
1) You said
* /etc/my.cnf settings are (no other my.cnf files exist):
* + default-character-set = utf8
* + character-set-server = utf8
In which section of the my.cnf file? Both for the server, or for the
client?
[client]
default-character-set = utf8
[mysqld]
Hi, Daniel
I'd also set the collation to *utf8_unicode_ci*. Here's a link to the full
diff of the *my.cnf* file I am using on my dev-server:
https://github.com/SimonSimCity/webserver-configuration/blob/master/mysql/patch.diff
Bye
Simon
2012/2/24 Daniel Convissor dani...@analysisandsolutions.com
Quick note:
If you're not storing Belarusian, Macedonian, Serbian, or Ukrainian or
have no need for *proper sorting* of the extra letters in these
languages NOR the support of expansions and ligatures; I would revert
to using utf8_general_ci, which is _slightly_ faster but converts all
chars to
On Fri, 2012-02-17 at 08:38 -0500, Daniel Convissor wrote:
A related problem was found by the test script. libmysql is completely
ignoring the character set information in my.cnf. Plus, if one forces a
character set by calling options(SET NAMES utf8) before connecting,
Hi Johannes and Ulf:
On Mon, Jan 23, 2012 at 09:56:00PM -0500, Daniel Convissor wrote:
Hi Johannes:
We have to live with the information the server gives us. The server
gives us the information in bytes. And frankly in PHP a string has no
encoding information, so in many cases that is a
Hi,
On Sat, 2012-01-21 at 08:31 -0500, Daniel Convissor wrote:
Hi Johannes:
The documentation tells
http://dev.mysql.com/doc/refman/5.5/en/c-api-data-structures.html
So it is working in bytes and has to hold all possible values.
That's how MySQL's
Hi Johannes:
We have to live with the information the server gives us. The server
gives us the information in bytes. And frankly in PHP a string has no
encoding information, so in many cases that is a good answer. But
nonetheless the documentation should be improved/fixed.
Further
Hi Johannes:
The documentation tells
http://dev.mysql.com/doc/refman/5.5/en/c-api-data-structures.html
So it is working in bytes and has to hold all possible values.
That's how MySQL's internal API works. At the same time, PHP's users
expect PHP to behave as
Hi,
On Fri, 2011-11-18 at 16:06 -0500, Daniel Convissor wrote:
The length property is what's tripping up my unit tests. I'm building
PHP 5.4 from svn for both tests. The only difference between them is
the with-mysqli declaration. Here is a table summarizing the situation:
type
Am 19.01.2012 13:50, schrieb Johannes Schlüter:
On Fri, 2011-11-18 at 16:06 -0500, Daniel Convissor wrote:
The length property is what's tripping up my unit tests. I'm building
PHP 5.4 from svn for both tests. The only difference between them is
the with-mysqli declaration. Here is a table
Gentlemen:
On Thu, Jan 19, 2012 at 02:09:12PM +0100, Ulf Wendel wrote:
Am 19.01.2012 13:50, schrieb Johannes Schlüter:
Your server seems to be configured for UTF-8 by default. In my tests the
behavior for both libraries (myslqnd libmsql) is the same if you mind
the character set (use SET
Am 19.01.2012 20:27, schrieb Daniel Convissor:
Gentlemen:
On Thu, Jan 19, 2012 at 02:09:12PM +0100, Ulf Wendel wrote:
Am 19.01.2012 13:50, schrieb Johannes Schlüter:
Your server seems to be configured for UTF-8 by default. In my tests the
behavior for both libraries (myslqnd libmsql) is
Hi:
On Thu, Jan 19, 2012 at 02:27:05PM -0500, Daniel Convissor wrote:
On Thu, Jan 19, 2012 at 02:09:12PM +0100, Ulf Wendel wrote:
Am 19.01.2012 13:50, schrieb Johannes Schlüter:
Your server seems to be configured for UTF-8 by default. In my tests the
behavior for both libraries (myslqnd
Hi Folks:
The output of mysqli_fetch_field() produces different results when
running against mysqlnd than it does against libmysql. I've mentioned
issues along these lines a couple times on the list in the midst of
other threads relating to MySQL handling, but nobody has really
addressed it
Hi Again:
type libmysql mysqlnd
---
CHAR(2) 26
Oh, by the way, I saw a CHAR(20) field come out as 60 in mysqlnd. So it
looks like the size is being multiplied by 3. Perhaps that's a clue for
debugging.
Thanks,
--Dan
--
T H E A N A L Y S I S A N
On 11/18/2011 01:06 PM, Daniel Convissor wrote:
Hi Folks:
The output of mysqli_fetch_field() produces different results when
running against mysqlnd than it does against libmysql. I've mentioned
Can you log a bug for this?
Chris
--
Email: christopher.jo...@oracle.com
Tel: +1 650 506
Hi Chris:
Can you log a bug for this?
https://bugs.php.net/bug.php?id=60333
Thanks,
--Dan
--
T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y
data intensive web and database programming
http://www.AnalysisAndSolutions.com/
4015 7th Ave #4,
19 matches
Mail list logo
