[peterlaursen]

Have you checked either of these:

*Lock all tables for read

*Flush logs before dump

If yes try uncheck them.

Well this 'Turkish issue' appears with direct connection as well.

Could you try you can write plain INSERT statements from SQL-pane with those characters?

Actually I am surprised that it works with HTTP. But your ISP has probably set up a special character-encoding-schema with the PHP configuration.

[peterlaursen]

Quote:

In gui how can I make SQL export ? Tools -> Export Database as SQL statements not work (Error No. 1044 Access denied for user xxx@IP.% to database xxx.

It that happens with HTTP-tunnel and user name has special charcater(s) to try replace in tunnelling file

$mysql = mysql_connect ( “$host:$port”, $username”, $pwd );

with

$mysql = mysql_connect ( “$host:$port”, “utf8-encode($username)”, $pwd );

But please be more precise on write isuue!

Can you write /INSERT/UPDATE) all those strings with Hungarian characters using HTTP-tunnel for the connection. Please try quite a lot of them! And from GUI as well as from SQL-pane.

[peterlaursen]

I also see that with auto-icrements you changed from

insert into `t1` (`id`,`t`) values ('','gh')

to

insert into `t1` (`id`,`t`) values ( NULL,'gh')

Much better in my opinion! 😀

And you found a solution so tha a literal CURRENT_TIMESTAMP does not become CURRENT_TIMESTAMP with multible saves!

Would you mind tell HOW that is implemented ?

[peterlaursen]

@Versatile

Fixed with Beta2. Can you confirm the fix?

[peterlaursen]

BETA 2:

I see that you changed the use of backquote from prefixing to surrounding. That's is OK.

writing “`NULL`” Inserts literal NULL Also “NULL” and “(NULL)” both insert NULL. I like that I can simply write “NULL”.

There is a small issue: writing “`(NULL)`” does not insert literal (NULL) but NULL.

Now it just has to be documented! @ritesh: You or I ??

[peterlaursen]

Are you using HTTP-tunnelling?

If yes, this http://www.webyog.com/forums/index.php?showtopic=1915 probably is the reason

There is an issue with special characters an MySQL >= 4.1 with HTTP.

Can you INSERT those strings from GUI with the same connection?

Please write some string examples here!

[peterlaursen]

A few observations more:

My MySQL 4.0 has the same charset for user table as the default charset (latin1). That explains that I can create user 'ølhund' (and it displays correctly) and 'write 'ølhund' and connect withe user 'ølhund' with HTTP without modifying the tunnel file on that mysql. Because the MySQL Latin1 is very similar to Western European ANSI that SQLyog uses on my system. For some strange reason I cannot create PW 'ølhund' – but that could be a hashing issue.

also check the PHP mb_convert_encoding() function!

[peterlaursen]

want to add: I did not check the CHARSET of user table with early MySQL version (3.23 and 4.0) It might be utf7!

[peterlaursen]

To support national characters with HTTP-tunnelling tunnelling file must start with:

[peterlaursen]

and:

http://dk.php.net/utf8-decode

http://dk.php.net/utf8-encode

I think usernames must be utf8-encode()d

so use something like mysql_connect(host,utf8-encode(user),password)

This works with a brief test in tunnelling file

$mysql= mysql_connect ( “$host:$port”, “utf8-encode($username)”, $pwd );

In a similar fashion they must be decode(d) when read from user table if SET NAMES does not SET utf8.

And actually the SET NAMES as of now does SET NAMES per database. As different columns may have different charset it should be done on a column-basis (ideally)

unfortunately I can't find a similar somple way for passwords.

But I also am not Ri Coder 😀

maybe it is necessary to hard-code a conversion table from ISO-8859-1 or utf-8 (if used with the tunnelling file) to MySQL latin1 into tunnel-file if pw's with special character shall work.

[peterlaursen]

this one should be a shell32.dll for W98SE

http://www.dll-downloads.com/hosts.asp?shell32.zip

try replace (make a backup of your existing file)

[peterlaursen]

Quote:

Can you import this Access database to anywhere else using the same ODBC-driver? No

What do you mean? Where did you try to import to/read with? If the ODBC-driver cannot read the Access file then SQLyog can't either! SQLyog does not read the Access file itself. If I understand you right then you must start fixing that problem then. Somehow.

W98 .. I don't have any chance to try this.

Some google links here. Seems to be a lot of problems with that shell32.dll. Anything you can use? There are links to downloadable versions, but have a copy of the one you have … But ritesh probably cal give a better explabation of ther error msag than I can.

[peterlaursen]

a little search:

http://support.microsoft.com/default.aspx?…Ben-us%3B138813

http://www.datamystic.com/textpipe/unicode_conversions.html

http://www.codeguru.com/forum/archive/inde…p/t-231165.html

http://www.firstobject.com/dn_markutf8ansiconv.htm

Conversion between ANSI and UTF-8 with the UTF8ToA and AToUTF8 functions is now supported in the Developer version of Release 6.6 available to those who have purchased a CMarkup Developer License. See UTF-8 ANSI Conversion Functions

[peterlaursen]

Now a little more.

1) Using 'ølhund' as password of course fails too with HTTP. *Access denied …etc*. That is true if user is created with direct connection! If user is created with HTTP-connection you can connect with HTTP, but not with direct connection!

2) let's have a look at the MySQL user table. It ALWAYS (no matter the actual charset settings) starts like

Code:

*Column Information For – mysql.user*/
—————————————

Field Type Collation
——————— ——————————— —————
Host char(60) utf8_bin
User char(16) utf8_bin
Password char(41) latin1_bin
Select_priv enum('N','Y') utf8_general_ci
Insert_priv enum('N','Y') utf8_general_ci

and all following columns are utf8_general_ci

Note particularly that Password is ALWAYS latin1! Other columns are UTF8.

Undoubtedly the C-API handles all this. But how to make PHP do?

php_mysqli extension has the mysqli_set_charset() function. php_mysql extension has not.

maybe this is not working with at all as of now. Conversion to UNICODE/UTF8 codebase with SQLyog should solve the issues – except possibly for password (i don't recall if ANSI and UTF maps characters 128-255 identically – but I doubt!) – but maybe MySQL converts itself?

3) Have a look at attached! Four users are created (created with SQLyog and direct connection):

'ølhund','øresundsfærge','tøsedræng','schäferhund'. They display like it shows in SQLyog. I can connect with all 4 with 'MySQL administrator' so they undoubtedly are saved correctly – SQLyog probably just is not aware that it is UNICODE! But all characters here are ANSI/latin1 – I would not try to guess what would happen if a character outside the ANSI/Latin1 range was used. Other users that have a change to try?

Also note that 'ølhund here is displayed as an empty string. And actually sometimes when I try to insert 'ølhund' MySQL returns the error 'query was empty'!

A Quote: http://www.acko.net/php-no-unicode-support

Quote:

This means that if you want to make a PHP application which supports any language and runs on the average PHP host out there, that there's only one option: use UTF-8 internally, and write your own functions for string truncation, email header encoding, validation, etc. Using UTF-8 ensures that you only have one encoding to worry about and because it's Unicode it is guaranteed to be able to represent any language.

Screenshot above shows user table as it ooks from SQLyog using HTTP.[attachment=387:attachment]

And this is with direct connection (as it should be): [attachment=388:attachment]

[peterlaursen]

Confirmed!

When the multitabbed feature was released with SQLyog 5.0 there was some arrows you could use to scroll the SQL window horisontally. Looks like it has disappeared with 5.01 or 5.02. Or rather they have!

See attached screenshot of 5.0

I can't tell the reason for this. Some code commented out by accident. Or bitmaps not available to compiler. But undoubtedly this is an easy fix!

[Author]

Posts