Script Object as ALTER feature should not use cached scripts
Please see forum thread http://www.red-gate.com/MessageBoard/viewtopic.php?t=14749
I ran into what I would consider a serious issue with the Script Object as ALTER feature. A few hours earlier I had changed a stored procedure script and executed the Alter script so the change was now "active".
A few hours later, within the same SSMS application (but different query window) I used the right-click Script Object option as a shortcut so I didn't have to scroll through a very long list in Object Explorer... Unfortunately it scripted the OLD version of the procedure and not the one changed hours earlier.
Now, I know this is because I didn't hit "Refresh Suggestions" (which I subsequently did and got the newer version), but my point is that this is exceptionally dangerous given an environment where changes are not always known by all individuals and where there is no DBA to manage all changes. I could have blown out hours of work or critical changes by executing the generated cache-scripted version and never known until all hell broke loose.
Is there a very compelling reason to use caching instead of just scripting the most current version (which SSMS does in pretty much the same amount of time)? Is it more compeeling than potentially causing changes to be whacked?
As of SQL Prompt 5.2.8, Script as ALTER will always fetch the script directly from the database.
Ed Bouras commented
Wonderful. Thank you for considering my feedback :)