Unsupported Screen Size: The viewport size is too small for the theme to render properly.

Bug: Copy Database To

forums forums SQLyog SQLyog: Bugs / Feature Requests Bug: Copy Database To

  • This topic is empty.
Viewing 4 reply threads
  • Author
    Posts
    • #10182
      kasi
      Member

      There is a bug when copying a database between servers, when you have HTTP Tunneling connection and a direct connection.

      This is because the tunneler sends the “set names utf8” only once and not when querying the data.

      So when you have two servers with default connection set to latin1, the source (tunnel) send the data as latin1 but the local connection is set to utf8.

      This results in loosing all special characters. 😮

      kasi

    • #23410
      peterlaursen
      Participant

      The SET NAMES statement is sent by the tunneller for every single statement.

      This PHP funticon is being caled every time!  So that is not the problem.

      Instead of you guessing the reason for this you could give us a test case so that we can solve it! 😉

      “So when you have two servers with default connection set to latin1, the source (tunnel) send the data as latin1 but the local connection is set to utf8.”  I do not uderstand.  You have two remote servers (latin1) and one local (utf8) – was that what you meant ??

      One idea: create the database that you copy to like before copying data:

      Code:
      CREATE DATABASE mydb DEFAULT CHARSET UTF8

      (not possible from the GUI at this moment unfortunately)

      I am not sure that this is related to HTTP at all, I think it is rather a limitation with the 'copy database/table' functionality … but please explain more in detail! 

    • #23411
      peterlaursen
      Participant

      BTW: always tell the program version!

      You should read this FAQ: http://webyog.com/faq/34_102_en.html

      You should NOT select neither 'default' or 'utf8' for the connection – not to a server with utf8 data either. Use the charset that corresponds to you windows localisation ('latin1' or whatever)!

      I am 99% sure that I understand now. And if I understand correct this is not at all HTTP-releated, but is ude to the fact that currently SQLyog uses ANSI internally. Same would occur with direct connection(s). With hindsight we should not have given the 'utf8' or 'ucs2' options in the connection manager. Because SQLyog cannaot handle a stream of UNICODE data. Only the Migration Tool can (and needs a SET NAMES UTF8 when importing Unicode data from an ODBC source).

      As we release 5.3 (that will use UNICODE internally) soon things will become easier! Easier to perform and easier to understand!

    • #23412
      kasi
      Member

      I am using SQLYog Enterprise 5.20

      peterlaursen wrote on Feb 14 2007, 06:28 AM:
      Instead of you guessing the reason for this you could give us a test case so that we can solve it! 😉

      I didn't guess the reason. I changed the the tunneler script, so that it dumps me all queries, that are send to the server, to a log-file. I alse dumped the connection state using “show variables like 'character_set_%'” before each mysql_query. So I know that the data from the database is in latin1 and I guessed that the server locally sends “set names utf8” because all special characters are gone.

      Also when I do “mysql_query('set names utf8') just after mysql_connect() everything works correct (except sending own queries).

      This only happens when doing “Copy selected database to an other HOST/DB”.

      Export as Batch-script and Database Synchonisation Wizard are working correct (doing set names utf8 and fetching utf8 data).

      KASI

    • #23413
      peterlaursen
      Participant

      I am 99.9% sure that this is not related to tunelling.  Same thing would happen with direct connections.

      'copy .. to other …' creates a new connection.  Maybe there is an issue that this new connection uses 'default' charset as 'default'.  And that would fail with uft8 data.

      I'll ask a developer to look detailed into this!

Viewing 4 reply threads
  • You must be logged in to reply to this topic.