Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

The Human Touch Expand / Collapse
Author
Message
Posted Sunday, August 4, 2013 4:40 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 8:59 AM
Points: 5,930, Visits: 8,181
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 MVP
Visit my SQL Server blog: http://sqlblog.com/blogs/hugo_kornelis
Post #1480796
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse