[peterlaursen]

when you are saying 'formerly' what is the version that you compare with?

For us DEFAULTS are displayed OK.  I do not understand how that is happening for you! Are you perfectly sure taht there are defaults defined?

Please attach a structure only dump to reproduce with!

[peterlaursen]

Please also explain

Quote:

Now I add a space in the title of record ID 2:

In phpmyadmin:

UPDATE `test` SET `post_title` = 'начать

руковод�тво ��кономленного ' WHERE `ID` = '2';

In sqlyog:

update `test` set `ID`='2',`post_title`='начать руководÑ?тво Ñ?Ñ?кономленного ',`post_status`='attachment' where `ID`='2'

So the sqlyog messes up:

начать руководство сэкономленного (original)

начать руковод?тво ??кономленного (after sqlyog)

This is not reproducable here!  If i add spaces after opening in the blob viewer spaces DO NOT become ?'s and the SQL from HISTORY goes like

update `test` set `ID`='2',`post_title`='начать Ñ€ÑƒÐºÐ¾Ð²Ð¾Ð´Ñ Ñ‚Ð²Ð¾ Ñ Ñ ÐºÐ¾Ð½Ð¾Ð¼Ð»ÐµÐ½Ð½Ð¾Ð³Ð¾',`post_status`='attachment' where `ID`='2'

But also I am not sure what you think is the issue now?

[peterlaursen]

@don

he uses BLOB fields for storing of strings.  SET NAMES has no effect on binary data (like ((var)binary and BLO:cool:.

He is storing some web based encoding as binary data, I believe!  His has a client program of some kind that does the encoding/decoding.

This is not MySQL unicode and we do not support it – whatever it is!

[peterlaursen]

currently this is not editable.

[peterlaursen]

I have no answer to this, but I never used anything but a 'user DSN' or 'system DSN' for Access.

[peterlaursen]

“but I am still wondering why other clients still can make sense of this without errors”  I do not know either.  Maybe becasue it is webbased/PHP.  Do you know any BINARY supporting this?

An example whre different charsets would make sense is a product catalogue of an international firm.  If 'rail' is 'lang-tung-ting' in Chinese (you need to be Dansih to understand the joke!) than you may have 2 columns – 1 displaying 'rail' in English and aanother 'lang-tung-ting' in Chinese.  But using Unicode all over would be easier of course.  But Unicode and PHP based web applications for instance also has its problems!

[peterlaursen]

Please read:

http://webyog.com/faq/32_145_en.html?highlight=debug

When SQlyog starts such zero-size file is created.  If no error occurs the fille will be deleted when SQLyog closes down.  There may be situations where SQLyog is killed 'ungraciously' where the file is not deleted.  Then next time the file name will be .001.  The file is without any importance.  You can delete it.

[peterlaursen]

please try open the dump in Notepad yourself.

all strings are stored in BLOB fields.  BLOB is a binary filed type, for strings you should use (var)char or text types.

Also this: ” ..values('4','Lấp lánh há»â€œn thÆ¡ Viá»â€¡t trên sân ga Tokyo chiá»ï¿½u cuá»â€˜i nÄÆ’m','','ký —”  clearly tells that data are NOT stored as Vietnamese in the database.  Looks like it is stored with som web-encoding.  I don't know exactly what it is, because I do not know Vietnamese, but this is NOT unicode!

There may be thousand ways to implement 'client side encoding'.  We do not support this.  SQLyog displays data as they are stored in the database.

[peterlaursen]

From your link I quote:

WP is running in semi-unicode and ascii/latin mode. As a result, people with weird languages that require UTF-8 character sets are having major problems. The issue isn't easily detectable, since storing and retreiving UTF-8 data to an SQL database with latin character set seems to work. Unfortuantely, it doesn't really work. WP can store UTF-8 data on a database/table/field with latin character set, but all SQL-based text functions return wrong values.

Quote:

semi-unicode and ascii/latin mode

I think that one day I will invent a moon made from green cheese and call it 'semi moon stone' 😉

This is very non-standard and probably origines from back in time where MySQL did not support unicode. This trick makes it possible to display data from different languages at the same time without using unicode.

Put another way, this system stores data as latin1 strings and does a 'client side encoding/decoding' where certain sequences of latin ASCII/ANSI characters has the meaning of non-latin characters.  But this is only the meaning of those data for this specific system. In my opinion you will only be able to read/write such data with the client software/scripts shipped with this system. 

SQLyog displays data as it is stored in the database!

but actully, I think the 'workaround' as described in the link too

Quote:

The solution is to ALTER all TEXT and related fields to BLOB, then alter the character set and finaly change back the BLOB fields to TEXT.

… would work actually! And that would be very easy with SQLyog actually!

[peterlaursen]

yes .. it would be possible to set some kind of flag for every cell in the grid that tells if it had been touched or not!  But we do not do it and there are no such actual plans!

[peterlaursen]

Quote:

This is common practice (in a lot of web based installers of cms/blog packages), but in case you have this conflict, SQLyog should see the inconsistency and report that it can lead to corrupted data and DENY the update, because corrupting data is the worst that can happen. … I consider this critical behaviour as extremely dangerous.

I am not sure I understand (or rather I am sure I do not understand!).  Columns will be created with the table default (if exists), next the database default (if exists) and only if neither exist the server default will be used.  Unless of course a charset or collation is explicitly specified for the column.

Could you please explain more in detail what you think SQLyog has done wrong here and what some other application has done wrong!

I do not understand either how SQLyog should deny creating columns with user-specified charsets.  There can be lots of situations where it makes good sense to have columns with different charsets.  Although using unicode would be preferable in most situations then (if all applications accesing the data support it).

[peterlaursen]

I think every GRID based GUI does like this.  The only exception is TIMESTAMP fields defined as 'ON UPDATE CURRENT_TIMESTAMP' because the server should update those with now()!

How should we check otherwise than comparing with data on the server?  That would demand the same or maybe more data to be transferred.

You can work from the RESULT tab and not the DATA tab and only the displayed columns will be updated.

[peterlaursen]

The charset DEFAULT is utf8, but every string column is defined as 'latin1'. That looks weird!

If you are not using SQLyog, what are you using now to generate this example!  How was the table and the data created?

What happens if you simply ALTER TABLE and define utf8 charset for the columns? (back up first!)

[peterlaursen]

what is your windows version?

Please read this FAQ: http://webyog.com/faq/32_145_en.html

One place to look is http://www.dll-files.com

.. last I checked there was a XP version there!

[peterlaursen]

i can add that the version on my Vista is 6.xxxxxxxxxxxxxx dated november 2006.

[Author]

Posts