Hi,
On Sep 6, 2012, at 1:24, Daniel Convissor
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.
>>
>>The serv
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
> resu
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 th
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
> Hi Johannes:
>
> > 1) You sai
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]
charact
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,
> > character_s
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 tha
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 experim
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 My
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 d
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 librari
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 th
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 (
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
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 l
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, Br
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 863
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
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 direc
19 matches
Mail list logo
