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 Thursday, August 1, 2013 10:24 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:38 AM
Points: 33,267, Visits: 15,436
Hugo Kornelis (8/1/2013)
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...)


Good points, and this is a complex subject. For using SSMS, you have issues either way, but with a script, at least you can see what's being done. I've actually done this and then avoided running the script because I could see it was a table drop and recreate, which was an issue.

In terms of PoSH and other scripting languages, I'd still assume you did testing, or expect you to test. Even your own scripts, and I would hope you take more care. You can make a mess of things much quicker with a script than you can with the GUI for sure.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1480023
Posted Thursday, August 1, 2013 10:26 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:38 AM
Points: 33,267, Visits: 15,436
RichB (8/1/2013)
I would also firmly point you towards Sidney Dekkers Field Guide to understanding Human Error.

In my opinion one of the cross disciplinary must reads for any DBA.


Interesting. Never heard of it, but added to my reading list.

It's here on Amazon: http://www.amazon.com/Field-Guide-Understanding-Human-Error/dp/0754648265







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1480025
Posted Thursday, August 1, 2013 10:29 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 12:38 AM
Points: 33,267, Visits: 15,436
patrickmcginnis59 10839 (8/1/2013)
paul.knibbs (8/1/2013)
That's all true, but I come from a programming background, and I know that you will pretty much never, ever anticipate every daft or incorrect input a user is capable of providing.

In my case, instead of ceasing programming, I instead looked for ways to simulate daft input, and have generalised this further into putting filters on input that required conditions to be "non daft" in nature

Not a perfect situation, I've been surprised before, made errors before, but in my opinion, during the course of scripting a task we can compress all of the analysis and synthesis of error handling into the exercise of scripting, whereas Hugo is stuck repeating all that analysis and synthesis DURING EACH MANUAL RUN OF HIS TASK.


There are risks either way, but you have to choose some method. The thing I'd say with a script is that I have the advantage of logging what happened and being able to debug it when I've made a mistake.

If I've clicked on a button, I am relying on my own (highly suspect and faulty) witness testimony to trace back the actions.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1480026
Posted Thursday, August 1, 2013 12:23 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Yesterday @ 7:20 PM
Points: 21,751, Visits: 15,449
Steve Jones - SSC Editor (8/1/2013)
patrickmcginnis59 10839 (8/1/2013)
paul.knibbs (8/1/2013)
That's all true, but I come from a programming background, and I know that you will pretty much never, ever anticipate every daft or incorrect input a user is capable of providing.

In my case, instead of ceasing programming, I instead looked for ways to simulate daft input, and have generalised this further into putting filters on input that required conditions to be "non daft" in nature

Not a perfect situation, I've been surprised before, made errors before, but in my opinion, during the course of scripting a task we can compress all of the analysis and synthesis of error handling into the exercise of scripting, whereas Hugo is stuck repeating all that analysis and synthesis DURING EACH MANUAL RUN OF HIS TASK.


There are risks either way, but you have to choose some method. The thing I'd say with a script is that I have the advantage of logging what happened and being able to debug it when I've made a mistake.

If I've clicked on a button, I am relying on my own (highly suspect and faulty) witness testimony to trace back the actions.


This is one of the biggest pros of using a script. It is reproducible and provides a "logging" mechanism of what has been done (almost self documenting). If that logging is not adequate, you can modify it to output to a log (file or table) what has been done and provide timing measures.

Though it is not foolproof, it can be easier to "debug" and discover what went wrong and where it went wrong.




Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1480075
Posted Thursday, August 1, 2013 12:46 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:00 PM
Points: 2,332, Visits: 1,390
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...


Not all gray hairs are Dinosaurs!
Post #1480093
Posted Thursday, August 1, 2013 1:33 PM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: 2 days ago @ 2:03 PM
Points: 1,335, Visits: 3,069
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. ..."
Post #1480118
Posted Thursday, August 1, 2013 2:07 PM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 12:00 PM
Points: 2,332, Visits: 1,390
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!
Post #1480128
Posted Thursday, August 1, 2013 3:57 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, January 23, 2014 2:24 PM
Points: 4, Visits: 16
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.
Post #1480192
Posted Friday, August 2, 2013 7:04 AM
SSCommitted

SSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommittedSSCommitted

Group: General Forum Members
Last Login: Today @ 3:34 AM
Points: 1,639, Visits: 5,621
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!
Post #1480370
Posted Sunday, August 4, 2013 3:58 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Thursday, January 23, 2014 2:24 PM
Points: 4, Visits: 16
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.
Post #1480792
« Prev Topic | Next Topic »

Add to briefcase ««123»»

Permissions Expand / Collapse