Comments
Sort by recent activity
Those are great suggestions- could you add them to our Uservoice forum so we can keep an eye on how popular an idea it is?
Thanks! / comments
Those are great suggestions- could you add them to our Uservoice forum so we can keep an eye on how popular an idea it is?
Thanks!
Which version are (were) you using? This was a known bug recently, but the latest download should resolve it. / comments
Which version are (were) you using? This was a known bug recently, but the latest download should resolve it.
Ah, yes, it probably isn't granular enough to help there. The other option you could look at is the slightly-more discoverable filtering, it works similarly to in SQL Compare: Filters / comments
Ah, yes, it probably isn't granular enough to help there. The other option you could look at is the slightly-more discoverable filtering, it works similarly to in SQL Compare: Filters
Hi,
One option that may help is to ignore the tSQLt objects. SQL Source Control has an option to exclude these, in amongst the Compare Engine settings. You can amend them as described here - look for one called IgnoreTSQLT / comments
Hi,
One option that may help is to ignore the tSQLt objects. SQL Source Control has an option to exclude these, in amongst the Compare Engine settings. You can amend them as described here - look f...
Thanks for posting this. I've run through the same steps and I do indeed get the same problem, therefore I've logged a bug (SOC-6102) to get it looked into.
You're right that we currently don't expose the Data Compare options in SQL Source Control (although this is something we're investigating adding). For now, I think you'll need to continue manually amending the update script. / comments
Thanks for posting this. I've run through the same steps and I do indeed get the same problem, therefore I've logged a bug (SOC-6102) to get it looked into.
You're right that we currently don't exp...
Thanks for that - don't worry too much on updating if it's a hassle. We've made a little headway here today and we've got some good leads on why this might be happening (the coincidence being the large number of stored procedures)
We're continuing to actively work on this, as a few people have hit it recently, so hopefully we'll get a fix out soon. / comments
Thanks for that - don't worry too much on updating if it's a hassle. We've made a little headway here today and we've got some good leads on why this might be happening (the coincidence being the l...
Thanks for your post, and sorry you're running into this.
We're looking into this now, and I can see one of the error reports you sent in to us in our system.
If you could continue to send those (unless you've reverted to an old version of course!) it would be useful. In addition, could you increase your log level to the maximum temporarily?
To do this, locate the file "RedGate_SQLSourceControl_Engine_EngineOptions.xml" - it'll be in c:\users\<your username>\appdata\local\red gate\sql source control 3
If you edit the file in Notepad (ensure SSMS is closed) and add this line:
<LogLevel>All</LogLevel>
In between the EngineOptions tags so it looks similar to the below: <?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!---->
<EngineOptions version="3" type="EngineOptions">
<DefaultTraceMinimumInterQueryTimeInMillis>3000</DefaultTraceMinimumInterQueryTimeInMillis>
<LogLevel>All</LogLevel>
</EngineOptions>
If you can also let us know if you've got any data in Source Control that would be useful (I know you mentioned you're filtering to just stored procedures, but filtering occurs later in the process rather than completely ignoring all other objects)
Out of interest, how many sprocs do you have?
Thanks! / comments
Thanks for your post, and sorry you're running into this.
We're looking into this now, and I can see one of the error reports you sent in to us in our system.
If you could continue to send those (u...
Shared model refers to the database being shared, rather than the svn repository- however you're right that the folder won't normally be empty once the first user has linked up.
The normal process when getting started with SQL Source Control would be for the first user to link to a new empty folder in SVN and commit everything. Other users would then link to the same place and will also be able to commit changes. The folder doesn't need to be empty for subsequent users because we add an empty file (called RedGate.ssc) to the folder so we know it's used by SQL Source Control.
If you're trying to link for the first time to an existing set of scripts (perhaps created by SQL Compare) then you'll just need to manually create that file for it to work. If the contents of that folder weren't created by our tools, then you may be linking to the wrong place though. / comments
Shared model refers to the database being shared, rather than the svn repository- however you're right that the folder won't normally be empty once the first user has linked up.
The normal process ...
The automation pack is still running Compare, so in theory the end result should be the same.
I'd probably begin by verifying that when you tested with Compare you used exactly the same source/target. In addition, check that you were using the same options as the automation command line is passing, and that you also included the same filter file (you'll need to load the filter into the Compare GUI)
The actual error you got looks like we were trying to drop something that SQL Server didn't allow as it was in use, so this may indicate a missing dependency when it's run through the automation side of things / comments
The automation pack is still running Compare, so in theory the end result should be the same.
I'd probably begin by verifying that when you tested with Compare you used exactly the same source/targ...
You could look at the automation pack- it's essentially command line versions of Compare (and some of the other tools) See here / comments
You could look at the automation pack- it's essentially command line versions of Compare (and some of the other tools) See here