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

SQLyog Support MySQL 5.x ?

forums forums SQLyog SQLyog: Bugs / Feature Requests SQLyog Support MySQL 5.x ?

  • This topic is empty.
Viewing 9 reply threads
  • Author
    Posts
    • #8970
      Yutthanai
      Member

      Are SQLyog Support MySQL 5.x or not?

    • #17762
      Ritesh
      Member

      You can very well connect and work with MySQL v5.x.

      As of now no GUI is available for strore procs/views etc. You have to write the correct SQL query in the editor window and execute it.

    • #17763
      Shadow
      Member

      Well, it's not just the lack of GUI support for stored procs that causes inconveniance, but INSERT/UPDATE commands fail to work if they involve special characters and client side encoding is set to utf8 using SET NAMES command. Encoding of underlying db or table(s) seems to be irrelevant to this issue. If the inserted/updated string contains special characters, an emtpy string gets inserted/updated.

      This was tested with SQLyog Ent. v4.06 on W2K with MySql v5.0.3 beta, InnoDB. Special characters in question belong to Hungarian alphabet.

    • #17764
      Shadow
      Member

      Upon further testing, we are not sure, that this is a bug in SQLyog, it may well be in MySql itself… I'll be posting command line screenshots later on.

    • #17765
      peterlaursen
      Participant

      There is a lot of bugfixes with each new release og Mysql ver. 5

      http://dev.mysql.com/doc/mysql/en/news-5-0-4.html

      http://dev.mysql.com/doc/mysql/en/news-5-0-5.html

      http://dev.mysql.com/doc/mysql/en/news-5-0-6.html

      With me Sqlyog works fine with MySQL 5.0.4. But it's not true what Ritesh writes, that SP-code can be executed fra the SQL-pane in SQLYOG. First: there is no support for DELIMITER command, second: the code is not recognized as SP-code (probably a problem with the library).

    • #17766
      Shadow
      Member

      5, and 6 are not even released yet…

      But here comes the first of the promised screenshots. Encoding was set to utf8 (table encoding is utf8 as well), and then we try to insert a new record. Field A is of int type (autoincrement), B and C are of varchar(45).

    • #17767
      Shadow
      Member

      But the most interesting results occured, when I switched to ucs2 encoding. Even the SELECT command should complete succesfully, but that USE command beats everything:

    • #17768
      peterlaursen
      Participant

      I guess I'll stick to the “latin1” character set! 😉

    • #17769
      peterlaursen
      Participant

      I just noted at http://www.mysql.com that 5.0.5 is just “not released” 5.0.6 is “not released yet”.

      My interpretation is that they will skip distribution of the 5.0.5-binaries. So 5.0.6 must be very close. Hope that could help you!

    • #17770
      Shadow
      Member

      Even latin1 produced interesting side effects, byte length of field A was 10, while byte length of field B was only 5 after the INSERT statement on the first screenshot had been executed…

      I guess, we won't be using MySql 5 beta for a while…

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