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!
