• I understand what you're saying, Steve. But there is also another side to the equation.

    First, on using the script button in SSMS.

    Using this button to generate code can be dangerous - especially if you trust the script blindly. I know that older versions of SSMS often created scripts that were buggy. (Worst example I have seen, I think from the SQL2005 version of SSMS, is a script that "changed" a table by creating a new one, copying the rows, then dropping the old table. I noticed that some of the BEGIN TRAN / COMMIT TRAN statements were in the wrong places - a server failure in the worst possible moment could result in losing all data in the table!). Of course, the same risk is present when executing from the SSMS dialogs (since that uses the same script, except without showing it to the user). And I have to add that the scripts have improved, though I have not really inspected them in detail since SQL2008.

    So my take would be that the script button is very important - not as a way to easily create reusable scripts, as you indicate in the article, but as a way to double check the script generated by SSMS and correct it if it's wrong, unsafe, or inefficient.

    Then, on using scripts and/or PowerShell in general.

    You push using this kind of automation as a way to prevent human error, because you eliminate the error-prone process of a human filling out a dialog and pressing buttons. However, humans working with a dialog *know* that they might make errors. They will usually try to prevent this by working carefully and checking what they do. Using a script gives a (sometimes false) sense of security. When people use a script, they expect it to work, period. But what if there is an error in the script? Or if the script fails to handle an unanticipated situation appropriately? If people just fire off the script and expect it to work, it can take a long time, and a lot of executions, before someone finds out. And by then, reparing the damage may be impossible.

    I'm not saying that your arguments have no value. They do. But there's another side to it as well. No black, no white, just different shades of grey. (And I guess I'd better resist the temptation to count how many...)


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/