Options
SC-10120: not fully fixed: it removes empty lines when pasting
kalo
Posts: 86 Bronze 5
in SQL Compare
SC-10120 fix in 13.4 regarding copying and pasting and the fix to preserve line endings. Although now when pasting the formatting has returned (Great!) it does not preserve the empty lines in the original code so these have to put in manually.
Tagged:
Best Answers
-
OptionsRob C
Posts: 419 Gold 2
Hi @kalo
Thanks for the heads up! It seems to be an edge case that only occurred when the "Ignore whitespace" option was set. If you turn off that option then it seems to work normally.
I've fixed the problem and the fix will go out in the next frequent update release.Software Engineer
Redgate Software -
OptionsRob C
Posts: 419 Gold 2
The fix went out this morning with the 13.4.4.6883 release.Software Engineer
Redgate Software
Answers
It does seem to be the case now that it not only copies the blank lines which are in the object but also the 'blank' lines where it is comparing against the other source so that when you paste the code from the window you don't actually paste the original code but the compared code
It used to be the case (i think) that if you select all and copy from the comparison window it just copied the code from whichever source you had chosen (so the same code as what would be deployed if you selected just that single object and stepped through the deployment wizard).
Or indeed behaves the same way the comparison panes work in SQL Source Control - where the copy paste just picks up the source code : if i update Source Control to the new frequent update that includes SC-10177 will it break this behaviour in this app too?
Sorry that you're still not happy with the diff viewer. I would be careful if you want the original object code because the diff viewer shows a creation script for the object that SQL Compare has created, based on the information it has registered. So for instance you may find that an inline index definition has been rewritten as an ALTER TABLE myTable ADD INDEX... statement. I would say it's more of a representation.
I think if I had selected text that includes blank lines, then copied that text to the clipboard, I would expect those blank lines to be present when I paste it. Is copying the object definition from the diff viewer something that you do regularly? I'd like to understand your use case more.
Redgate Software
I do use it a lot which is why it feels like one of the recent updates has accidentally changed how it behaves : I might be entirely wrong on that, maybe it's always behaved like that.
However the diff pane in SQL Source Control doesn't copy the skipped lines so what gets pasted is the actual source code.
My immediate concern is that the release notes for the 6.2.2 update Source Control is telling me is available references SC-10177: Copying text from the diff viewer now preserves empty lines when the "Ignore whitespace" option is selected : as SC-10177 is the fix that went into SQL Compare to fix that issue, i'm worried that if i update then the Source Control behaviour will change from what it does now. I could update to find out i guess, but then I lose the behavour i want.
Now why do I copy from the diff pane so much?
I manage a number of 'mirror' databases which different versions of our dotnet code are pointing at - so i am frequently syncing these, now when i am only having to deploy one object (or want to deploy me objects one by one) then rather than having to go through the few steps of the deployment wizard and then wait for the application to follow up with the recalculation (Which can take a while on my big database), it is easier for me to just copy the diff pane script (from compare or source control) and change the CREATE to an ALTER
Secondly, if i do decide to do a deployment through SQL Compare, i find that the Commit dependencies will pop up and detect various objects that i don't want to deploy in the batch, like dependencies up the chain rather than down or objects which are of one type but perhaps a synonym on my mirror database (some i might want to deploy, but the wizard allows you only to select all or nothing, so i have to cancel out and go back to the differences screen to individually select the ones i want)
When you say "recalculation", are you referring to the recalculation that is done after the deployment? If so, you can turn that off in the deployment wizard - see below.
The ideal scenario sounds like it would be to make it easier for you to deploy. We're aware that there are some issues around the current implementation of selecting dependencies - at the moment it's a binary all or nothing choice. If you could choose whether or not to deploy individual dependencies, it sounds like that would improve things for you.
To be honest, I'm not certain about SQL Source Control's diff viewer. I don't think it's shared with SQL Compare, but I'll look into it.
Redgate Software
Yes, as writing my response I thought you might point out the recompare setting but that's a case of remembering to keep toggling it on and off between the different scenarios i'm using the compare tool for, so it's easier to copy and paste, but what i do know is just open up the wizard to the point of showing the script and copy and paste from there so if the diff viewer has to stay as it is going forward then i can still do what i want (just with an extra couple of clicks)
Yes, i would say the single change for me that could happen in SQL Compare - which would have me going out for drinks to celebrate - would be making that dependencies step on the wizard much more sophisticated. At the very least being able to individually select. it is useful though that you can do a comparison of those objects and decide if you need to include, so at the moment i use that to review copy and paste the object names i want to include into notepad, then cancel out of the wizard and individually paste in the object names back into the search box (having to remove the schema and squared brackets unfortunately) and select them one by one manually. So feels that process could be done for me by the tool.
Thanks for taking the time to respond and if you confirm whether the source-control behaviour has changed that would be great.
It seems that SQL Source Control has its own diff viewer so any changes to the one in SQL Compare shouldn't affect SQL Source Control.
Redgate Software