August 1, 2013 at 1:33 pm
Miles Neale (8/1/2013)
Thanks Steve.To Error a few times is Human, to error repeatedly doing the same thing is insane! To write a script to replication the error is well beyond the pale.
Miles...
True story. Mistakes and errors happen, just own up to them and learn from them. The major rub comes into play when one tries to cover them up or blame others. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
August 1, 2013 at 2:07 pm
TravisDBA (8/1/2013)
Miles Neale (8/1/2013)
Thanks Steve.To Error a few times is Human, to error repeatedly doing the same thing is insane! To write a script to replication the error is well beyond the pale.
Miles...
True story. Mistakes and errors happen, just own up to them and learn from them. The major rub comes into play when one tries to cover them up or blame others. 😀
Well said! Pointing fingers does not get the issue resolved, it only creates a larger one.
Not all gray hairs are Dinosaurs!
August 1, 2013 at 3:57 pm
This is an incredibly interesting topic and it appears there are pros and cons for scripting / not scripting. I almost always press the script button when I am doing something in SQL even just to check what it thinks it is going to do if I press the commit button. It may be overcautious but it is also how you gain confidence and understanding.
If the script button it is going to generate what it is going to run then how can the system generate buggy scripts? I have never seen this. It may generate scripts which are complicated and not palatable to understand or scripts which may error or take to long because of the data you have.
If you take the time to understand them then you have learnt something new and gained a better understanding of the environment you work in and eventually it all becomes an old hat.
The way I think about it is:
- If the task needs to be repeated more than twice then there is no question a script should be generated.
- Scripts can be reviewed by piers. No one in this day and age should live in a bubble.
- Scripts can be tweaked if necessary.
- A script may product some in-site into the system and make you think of a better way to complete a complex task.
Some of this borders on DevOps, if it is truly a regular / repeatable task then it must be scripted.
August 2, 2013 at 7:04 am
Shawn Richards (8/1/2013)
If the script button it is going to generate what it is going to run then how can the system generate buggy scripts?
The same way a compiler can produce buggy code that doesn't do what the source says it should--or maybe DOES do it, but in an odd way. (My favourite example of that was when I wrote a simple loop in Visual C++ that took *ages* to execute. When I told the compiler to output the intermediate assembly code it was producing, I was somewhat surprised to find that this very simple little loop had translated into more than 3K of assembly language...and even more surprised when, as an experiment, I just deleted a single space and re-ran the compile, and now the code was down to the sort of size I expected it to be and the program ran fine). SSMS is a program written by humans, and as such, it can contain errors that will cause unexpected results!
August 4, 2013 at 3:58 pm
paul.knibbs (8/2/2013)
Shawn Richards (8/1/2013)
If the script button it is going to generate what it is going to run then how can the system generate buggy scripts?
The same way a compiler can produce buggy code that doesn't do what the source says it should--or maybe DOES do it, but in an odd way. (My favorite example of that was when I wrote a simple loop in Visual C++ that took *ages* to execute. When I told the compiler to output the intermediate assembly code it was producing, I was somewhat surprised to find that this very simple little loop had translated into more than 3K of assembly language...and even more surprised when, as an experiment, I just deleted a single space and re-ran the compile, and now the code was down to the sort of size I expected it to be and the program ran fine). SSMS is a program written by humans, and as such, it can contain errors that will cause unexpected results!
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.
August 4, 2013 at 4:40 pm
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.
Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply