Comments
Sort by recent activity
There are no plans to support Git at the moment. If this is something you need, please post a suggestion at http://redgate.uservoice.com/forums/390 ... ce-control. This suggestion currently doesn't exist.
We are looking at polls that describe source control systems popularity over time. SVN and TFS seem to be the most used right now and have been increasing in usage over the past 2 years. Git is on that poll, so we'll be looking at its popularity.
Btw, it's great to hear that you are hyped about SQL Source Control. We love hearing this type of stuff and are so glad that you are finding it useful in your environment! :-) Please continue to post problems to these Support Forums or post suggestions to our Suggestion Forum as you continue to evaluate SQL Source Control. / comments
There are no plans to support Git at the moment. If this is something you need, please post a suggestion at http://redgate.uservoice.com/forums/390 ... ce-control. This suggestion currently doesn...
Hi Justin,
Thanks for checking the svn:needs-lock properties. We're looking into other settings to counteract this. Our internal reference number is SOC-719 and you should be hearing from us soon. / comments
Hi Justin,
Thanks for checking the svn:needs-lock properties. We're looking into other settings to counteract this. Our internal reference number is SOC-719 and you should be hearing from us soon.
This issue was caused by a seperate SVN plug-in caused SVNSCC by Pushok Software. If you have this plug-in installed, use the following workaround:
To get SQL Source Control and SVNSCC to work together, we need to configure SVNSCC not to modify attributes on the check outs used by SQL Source Control. As far as I can tell, the best way to do this is:
1) Unlink all your SVN databases in SQL Source Control (Right click on each database, select 'Other SQL Source Control Tasks' then click 'Unlink database from source control.')
2) Close SSMS
2) Bring up a command prompt (Start+R, type in cmd and click ok)
3) Type or copy and paste in the line below changing <username> to be your windows login, and press enter
echo pushok::rwmon=skip-tree>"C:\Users\<username>\AppData\Local\Red Gate\.pushokprops"
4) Run the 'SSC RW Monitor' (under Start->All Programs->Pushok Software)
5) In the dialog that appears, click "Cleanup and Restart"
6) When it has finished processing, SQL Source Control should work (You will need to relink your databases) / comments
This issue was caused by a seperate SVN plug-in caused SVNSCC by Pushok Software. If you have this plug-in installed, use the following workaround:
To get SQL Source Control and SVNSCC to work tog...
SQL Source Control should NOT be locking your files. I think it might be a setting on your Subversion server. Do you have TortoiseSVN installed? If so:
1) Right click on C:\Users\justin.collazo\AppData\Local\Red Gate\SQL Source Control 0\WorkingBases\fc53bc1b-0e4b-4af9-9070-8aef7175a516\Tables\HumanResources.EmployeeDepartmentHistory.sql
and select Properties
2) Select the "Subversion" tab at the top
3) Click the "Properties..." button near the bottom
4) Is there a svn:needs-lock property? If so, remove it.
5) Click OK to close the SVN properties window
6) Click OK to close the file properties window
7) Right click again and commit the change to Subversion (this is just committing the change that a lock is not needed on that file)
Now, you should be able to commit the file from SQL Source Control with out getting this permission error. Please let us know if you still have any problems.
You'll want to talk to your SVN administrator about the settings on your SVN server and see if you can remove the svn:needs-lock on your area. This way, you won't have this permission problem happen again. You'll need to remove the needs-lock property from all your existing files. / comments
SQL Source Control should NOT be locking your files. I think it might be a setting on your Subversion server. Do you have TortoiseSVN installed? If so:
1) Right click on C:\Users\justin.collazo\...
Changing the order of columns in a table does NOT appear as an edit. This is expected behaviour. We currently don't treat this as a change. If this is something you need/want, please add a suggestion to http://redgate.uservoice.com/forums/390 ... ce-control . This will allow other users to comment and vote on this idea so we can see how many people really want this. Thank you! / comments
Changing the order of columns in a table does NOT appear as an edit. This is expected behaviour. We currently don't treat this as a change. If this is something you need/want, please add a sugge...
There's no way to exclude db objects in the current version of SQL Source Control. If this is something you need, please vote/comment on the suggestion at http://redgate.uservoice.com/forums/390 ... ?ref=title. / comments
There's no way to exclude db objects in the current version of SQL Source Control. If this is something you need, please vote/comment on the suggestion athttp://redgate.uservoice.com/forums/390 .....
In EA2 (v0.2.1 - available on 22 Feb), we added a check that if you are using SSMS 2008 R2, we don't raise an error anymore, but just provide notification that SQL Source Control is currently unavailable for SSMS 2008 R2. This should mean that you shouldn't have to change your registry settings and can still work with SQL Source Control in SSMS 2005 for now. / comments
In EA2 (v0.2.1 - available on 22 Feb), we added a check that if you are using SSMS 2008 R2, we don't raise an error anymore, but just provide notification that SQL Source Control is currently unava...
It looks like we are having a problem parsing the following stored procedure:
C:\Users\DBachman\AppData\Local\Red Gate\SQL Source Control 0\WorkingBases\798f80c1-7997-4372-963e-a5827d6e0ec0\Stored Procedures\dbo.sproc_System_SSBQueue_Predicto_MessageReceive_Process_TopN.sql
From the information you provided:
'line 55:33: unexpected token: [";",<631>,line=55,col=33] [char=1233]'
There's a known issue about semi-colons with 2008 stored procedures, which we are currently working (internal reference number SOC-600).
But, it seems like there may be another issue because it shows that a problem actually occurs on another line:
'line 43:17: expecting "Integer", found '@N''
Could you please email the stored procedure to SqlSourceControlSupport@red-gate.com so we can replicate your issue and make sure we can parse it correctly?
Thank you! / comments
It looks like we are having a problem parsing the following stored procedure:
C:\Users\DBachman\AppData\Local\Red Gate\SQL Source Control 0\WorkingBases\798f80c1-7997-4372-963e-a5827d6e0ec0\Stored ...
Screenshots were very helpful. Thank you. Our internal reference number is SOC-672. We want to make sure that you can see both links at all times regardless of your screen resolution or if you shrink SSMS. / comments
Screenshots were very helpful. Thank you. Our internal reference number is SOC-672. We want to make sure that you can see both links at all times regardless of your screen resolution or if you s...
What is the exact error message that you got? You should be able to link mulitple dbs to the same repository. This is how team members would share changes with each other if they are all developing against their own dedicated db.
On the setup tab, you should use the "Create link..." when linking the first db.
When linking the second db, use the "Link to a db already in source control..." link.
The 2 links are seperate. In the first case, the repository should be empty. In the 2nd case, you need to specifiy a repository folder that contains a RedGate.ssc file. This will set up the links correctly.
If the dbs are 98% identical, we'll try to figure out which version you're at and only show the differences. There are a few known issues around this currently, e.g., if you have an object that is the same, but it's dependency is not, which we're currently working on. / comments
What is the exact error message that you got? You should be able to link mulitple dbs to the same repository. This is how team members would share changes with each other if they are all developi...