Comments
Sort by recent activity
Here is a video of the behavior I am referring to.
You can see that the GET operation fails, but there are 3 new users that are created even though the GET failed and there are no COMMIT actions to roll back. http://screencast.com/t/ruVcrC8ozHGE / comments
Here is a video of the behavior I am referring to.
You can see that the GET operation fails, but there are 3 new users that are created even though the GET failed and there are no COMMIT actions to...
Hi Ricky,
Thanks - I dont think its a support issue per se, more like a feature request - let me clarify.
In the SC 3 pending commit window, or the get latest window, you see the SQL owner of an object, but you cannot tell who actually made the change unless you inspect the repo logs.
It would be nice if the SC 3 window listed "who" was responsible for checking in "what". This would avoid the extra work behind trying to figure out who checked in what in a multi developer environment. Whether shared or dedicated, this information would be helpful.
The other, related thing is identifying who made a db change if that change was made outside of SC 3.
In my test, I asked a user who has permissions to the database granted to his AD account, but no SC 3 install, to make a change to an object so that we could see how it behaved for those who DID have SC 3 installed. Since the object owner is listed (and not the person who made the change), it isn't at all clear who modified the object - just that it's been modified.
To mitigate this I thought we could implement auditing, which would at least catalog that an object was modified by someone. But it would be nice if there were a way to identify (perhaps there is - I'm evaluating and I may just be missing it!) who explicitly made a change, not just by object owner, but actual user login (whether it was SA, a domain account, etc).
I hope that is clearer! / comments
Hi Ricky,
Thanks - I dont think its a support issue per se, more like a feature request - let me clarify.
In the SC 3 pending commit window, or the get latest window, you see the SQL owner of an ob...
I think we may go down the auditing path, at least first stage. Thanks. Would love to hear other input, as I'm more of a developer than a DBA. / comments
I think we may go down the auditing path, at least first stage. Thanks. Would love to hear other input, as I'm more of a developer than a DBA.
I am also experiencing this while evaluating SQL Compare and SQL Source Control.
In my instance, if I choose to Create a deployment script (after choosing which items were correctly identified for deployment), the transaction keyword level is not specified and I end up with errors like
"Incorrect syntax near 'LEVEL'"
And it only works if I manually add the type in the script window and execute it. / comments
I am also experiencing this while evaluating SQL Compare and SQL Source Control.
In my instance, if I choose to Create a deployment script (after choosing which items were correctly identified for ...