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

5.16 Beta 9 – Migration Toolkit

forums › forums › SQLyog › SQLyog BETA Discussions › 5.16 Beta 9 – Migration Toolkit

  • This topic is empty.
Viewing 3 reply threads
  • Author
    Posts
    • July 21, 2006 at 2:38 pm #21992
      peterlaursen
      Participant

      Actually the problem that you have with beta9 is becauase we SOLVED it.

      Believe it or not!

      it is 'DEFAULT getdate()' that is the problem. getdate() is not available in MySQL. From the Map option you can enter the MySQL equivalent “now()” or “CURRENT_TIMESTAMP” (they are synonyms).

      Before beta 9 SJA/Migration 'quoted' DEFAULTs. Beta9 does not and you can enter KEYWORDS and FUNCTIONS that MySQL accepts as DEFAULTs.

      Before beta9 there was no way. Any quoted 'string' would raise an error with MySQL Timestamps.

      Some day in the future we may build in the program some small 'conversion tables' for converting from SQL server, Oracle, Sybase etc. But we actually had a user in our ticket system yesterday that needed a usable fix IMMEDIATELY.

    • July 21, 2006 at 2:41 pm #21993
      intel352
      Member

      okay, thanks for the info. does it seem to you that “getdate()” is the only function that needs to be converted? (according to the error logs?)

    • July 21, 2006 at 2:50 pm #21994
      peterlaursen
      Participant

      I actually I think so!

      The MySQL parser is not very 'precise' in spotting the exact place. That is due to caching, code optimizing etc (actually a lot of code gets rewritten by the MySQL optimizer). It is common that the syntax error is 20-50 characters before the parser says 'stop. I had enough'! And I have seen it much before that.

      Is is not syntax debugging comparable to a compiler/IDE!

      And as far as I can see there are getdate()'s not so far from/before the error message. 'not so far' in MySQL parser terms.

    • July 21, 2006 at 3:04 pm #21995
      peterlaursen
      Participant

      Two more details:

      1) Note that there can only be one column defined as 'default CURRENT_TIMESTAMP' in a MySQL table. If you try to insert more now()'s or CURRENT_TIMESTAMP's as defaults only the first will be effective. The next(s) will silently be converted to 'default 0000-00_00 00:00:00' (at least hat was what happened to me when I tsted this with Acces yesterday)

      2) If you wnat to use the TIMESTAMP defined as

      'default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP' you will have to execute the appropriate SQL statement (ALTER TABLE) after the import. You can do from a 'Notifications Service' job running in the same batch as the Migration. SJA does not have a monkeyman's chance to know if you will use this clause or not!

      See MySQL documentation at:

      http://dev.mysql.com/doc/refman/5.0/en/timestamp-4-1.html

      When we have checked other ODBC sources (Oracle, Interbase, Sybase etc) for similar issues we will of course document it. Maybe even over time implement code that solves most cases 'automatically'

  • Author
    Posts
Viewing 3 reply threads
  • You must be logged in to reply to this topic.