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

Very Important

forums forums SQLyog SQLyog: Bugs / Feature Requests Very Important

  • This topic is empty.
Viewing 1 reply thread
  • Author
    Posts
    • #25462
      peterlaursen
      Participant

      This ALTER … was never considered a sync tool. Structure Sync will let you sync without touching thedatabase ..

      You have experienced this as 'extemely dangerous'. The other way around (not specifying the database) may be equally dangerous – if you by mistake hit a database in the Object Browser the statements will execute where you hit. Other users may NOT be aware of that changing the database context changes where it executes!

      You should understand the meaning of the SQL you are executing, basically!

      We populate the TEMPLATE from the returns of 'show create procedure'. The server returns like that.

      Maybe we can implement by querying from Information_Schema ..

      Anyway we use database identifier with DROP and not with CREATE stmt. Looks like a mistake – or at least an inconsequence.

    • #25463
      Simon Woolf
      Member

      Thanks for your very speedy reply Peter!

      peterlaursen wrote on Nov 29 2007, 01:50 PM:
      This ALTER … was never considered a sync tool. Structure Sync will let you sync without touching thedatabase ..

      That's understood – and structure sync is a great tool when we need to syncronise an entire database and make sure it's identical to another. However, frequently it's useful just to quickly apply an update for a single stored procedure – for example when rolling out a bug fix or a patch. In this case, structure sync is overkill.

      Quote:
      You have experienced this as 'extemely dangerous'. The other way around (not specifying the database) may be equally dangerous – if you by mistake hit a database in the Object Browser the statements will execute where you hit. Other users may NOT be aware of that changing the database context changes where it executes!

      I take your point – but the main problem with the script as is, is that it's inconsistent. The database name should either a) be specified for both drop and create statements, or 😎 it should not be specified for either. I would hold that the inconsistency actually leads to more confusion, not less.

      Quote:
      Anyway we use database identifier with DROP and not with CREATE stmt. Looks like a mistake – or at least an inconsequence.

      Yes indeed, just what I was getting at above. Fingers crossed that information_Schema might return something more useful!

Viewing 1 reply thread
  • You must be logged in to reply to this topic.