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

Database Dump And Issue With Timestamp Column Data No Treated As A Str

forums forums SQLyog SQLyog: Bugs / Feature Requests Database Dump And Issue With Timestamp Column Data No Treated As A Str

Tagged: , ,

This topic contains 3 replies, has 0 voices, and was last updated by  treadmill 6 years, 9 months ago.

  • Author
    Posts
  • #33263

    jonb2
    Member

    PS.

    A. I have just checked Heidi, it does what I want. It saves the edit.

    'ashwin' wrote:

    @jonb2.. We checked with HeidiSQL. Yes, they do allow to edit and save trigger. But..on SAVE they execute these queries(Checked from their query LOG)-

    Code:
    DROP TRIGGER `customer_create_date`;
    /* 0 rows affected. */
    CREATE DEFINER=`root`@`localhost` TRIGGER `customer_create_date` BEFORE INSERT ON `customer` FOR EACH ROW SET NEW.create_date = NOW();

    Now, with SQLyog when you do Execute All these queries are executed-

    Code:
    DROP TRIGGER /*!50032 IF EXISTS */ `customer_create_date`;
    CREATE ;

    Priority fix, of course!

  • #12857

    treadmill
    Member

    In the current release 10.4, there is most definitely a bug in the database backup. Any column that is a timestamp is not exported as a string – it has no single-quotes around the data, therefore all restores fail.

    This is causing major issues for our backups regime, please can you supply an immediate fix for this asap.

    In the meantime, can you supply a previous version 10.2 or 10.3 so I can continue backups, as this is critical.

  • #33984

    ashwin
    Member

    We have fixed and released v10.41. Refer: http://blog.webyog.com/2012/11/21/sqlyog-mysql-gui-10-41-released/

  • #33985

    treadmill
    Member

    Fantastic, thank you very much for such a quick fix release. 🙂

You must be logged in to reply to this topic.