May 12, 2017 at 1:59 pm
OK, I looked for this in these forums and various other places but found nothing. I almost ruined my query which would have inadvertently damaged our production DB. I want to submit it to MS Connect as a bug but would like peer feedback first...
Situation: Clicking "Undo" or pressing CTRL+Z can remove whole lines from the bottom of a query and you won't be aware because it looks like nothing happened. In a typical 'Undo' your cursor jumps to that area and you can see it "undo". I'll demonstrate a situation where an Undo action occurs and you might not notice it.
How to Reproduce:
My situation:
If you inadvertently remove multiple lines from the bottom of the query, which is typically your WHERE clause, then you're altering the query significantly. In my case, I made a small change to the Select statement, did CTRL+Z a few times to undo all the changes and didn't realize I had gone too far. I then made another quick change, considered my work done and was about to press F5 but instead I scrolled down and that's when I noticed there was NO Where clause. I knew this view had a where clause so I started digging into it and here I am presenting the issue to all of you.
Is it just me or is this a bug? In my opinion, the scripting process shouldn't be holding any 'Undo' actions but it does. After scripting an object, the 'Undo' drop-down menu has "Text Buffer Change" listed, one for each line scripted. Regardless, the real problem is that your cursor doesn't even jump to the change that's occurring once you select any of those "Text Buffer Change" entries.
Please don't flame me for working in the production environment. I think we can all see where this bug could haunt you, even if it was a test environment and a small change doesn't get fully vetted.
May 12, 2017 at 2:32 pm
I wouldn't class it as a bug, more "as-designed" due to how they get the definition of an object and "print" it to screen line by line. As you say there is the text buffer for each line which corresponds to the line being undo'ed.
You would have to press Ctrl+z at least 4 more times that you intended to for it to be an issue as there is always 3 lines of white space at the bottom of anything you have scripted, plus the GO line, plus any whitespace at the end of your object.
May 12, 2017 at 2:54 pm
FridayNightGiant - Friday, May 12, 2017 2:32 PMI wouldn't class it as a bug, more "as-designed" due to how they get the definition of an object and "print" it to screen line by line. As you say there is the text buffer for each line which corresponds to the line being undo'ed.You would have to press Ctrl+z at least 4 more times that you intended to for it to be an issue as there is always 3 lines of white space at the bottom of anything you have scripted, plus the GO line, plus any whitespace at the end of your object.
To me the bug is that it doesn't jump to where it's being undo'ed. Any other undo I've ever done, the cursor takes you to that location. If NO undo action is available, the screen and cursor do nothing, which, again, leads me to why I think this is a bad bug. I thought nothing was happening and my "WHERE" clause was completely gone. As you pointed out, I removed 4 lines (including the "GO") and the WHERE clause and wasn't even aware of it.
May 12, 2017 at 3:07 pm
I'm not sure how much traction your request will get, but I suppose you could try.
The trick is that it's not an unusual behavior of undo that's at play.
It's the actions taken by the scripting option that are unusual; the cursor jumps around in "normal" undo actions because of the original actions that are being undone.
I've seen behaviors far more impacting get closed as "Won't Fix", so I doubt they'll change the behavior of the scripting option for this.
My prediction is that they'll suggest a workaround of scripting to clipboard, and then pasting into a query window. You'll definitely notice if that gets undone 🙂
You might as well try, I suppose. Good luck!
May 15, 2017 at 10:03 am
Jacob Wilkins - Friday, May 12, 2017 3:07 PMI'm not sure how much traction your request will get, but I suppose you could try.The trick is that it's not an unusual behavior of undo that's at play.
It's the actions taken by the scripting option that are unusual; the cursor jumps around in "normal" undo actions because of the original actions that are being undone.
I've seen behaviors far more impacting get closed as "Won't Fix", so I doubt they'll change the behavior of the scripting option for this.
My prediction is that they'll suggest a workaround of scripting to clipboard, and then pasting into a query window. You'll definitely notice if that gets undone 🙂
You might as well try, I suppose. Good luck!
Well, as the saying goes, if it had been a snake, I would have gotten bit. I've never even considered scripting to the clipboard despite the fact that it's an available option in that menu. Now that I know about it, I absolutely will use this as a workaround as it's simple enough to do.
As for submitting this as a bug, I agree that it will probably be a "Won't Fix" situation. I also agree with your comment "It's the action taken by the scripting option that's unusual". After scripting. the undo button's drop-down menu shows "Text Buffer Change", one for each line that was scripted. If this is the reason an 'undo' won't jump to that location, it would seem the workaround you've pointed out should be how the scripting is done to begin with. SSMS should copy to clipboard and paste to new tab...maybe even with a temporary clipboard so as not to disrupt my main clipboard.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply