• Shawn Richards (8/4/2013)


    I don't disagree. However bad code that runs and fulfills the requirements which are set out is not buggy it is just bad. I did go on to say that it may product scripts which we don't like or take to long to run, just that i have never seen it to product buggy code i.e. code that will not fulfill the requirements which were set out via the interface.

    I know it does not always product good code which is why I almost always use the script button to understand what it is going to do and then assess.

    To clarify, I think I started this by mentioning the buggy code generated by (older versions of) SSMS. And I maintain that it was buggy, even though you would normally not see them. Sometimes, code can have bugs that only show up under unlikely conditions.

    In this specific case (and I don't recall the exact details, you'll have to trust my memory on this), there were some badly misplaced BEGIN TRAN and COMMIT TRAN statements in a script that recreated a table by dropping and creating it, using select into to save the current data. Under very specific, and hard to reproduce, circumstances, the misplaced transaction statements would result in the database not restoring to a consistent state if an outage occurred at just the right (or maybe I should say wrong) moment.


    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/