Comments
Sort by recent activity
Hi,
We have opened a support ticket to deal with your issue and will contact you shortly.
Thank you, / comments
Hi,
We have opened a support ticket to deal with your issue and will contact you shortly.
Thank you,
Hi,
I am afraid that SQL Source Control does not have an API/SDK that would allow you to do this, and it's not possible to do it with a SQL query.
The only way to check the list of changes to commit is interactively through SSMS.
Thank you, / comments
Hi,
I am afraid that SQL Source Control does not have an API/SDK that would allow you to do this, and it's not possible to do it with a SQL query.
The only way to check the list of changes to commi...
Hi Andrew,
I have logged a support ticket regarding this issue and will communicate with you through email.
You should be getting an email from us within the next few minutes.
Thank you, / comments
Hi Andrew,
I have logged a support ticket regarding this issue and will communicate with you through email.
You should be getting an email from us within the next few minutes.
Thank you,
Conclusion:
This appeared to be due to an issue with a TeamForge SVN repository. User was able to workaround this issue by re-linking to a local SVN repository / comments
Conclusion:
This appeared to be due to an issue with a TeamForge SVN repository. User was able to workaround this issue by re-linking to a local SVN repository
Hi,
I am afraid that the SQL Instance and Database combination must be different for that not to happen.
Thank you, / comments
Hi,
I am afraid that the SQL Instance and Database combination must be different for that not to happen.
Thank you,
Thank you for your post.
We are planning to add SVN 1.9 support within the next few weeks, so hopefully this workaround will not be needed for much longer!
Please check our Frequent Updates Release notes for updates on this: http://documentation.red-gate.com/displ ... ease+notes / comments
Thank you for your post.
We are planning to add SVN 1.9 support within the next few weeks, so hopefully this workaround will not be needed for much longer!
Please check our Frequent Updates Release...
The latest version of SQL Source Control available on the Frequent Updates channel (version 4.1.5) now supports SVN 1.9 / comments
The latest version of SQL Source Control available on the Frequent Updates channel (version 4.1.5) now supports SVN 1.9
Hi,
I have opened a support incident for this issue and will contact you using that channel.
Thank you, / comments
Hi,
I have opened a support incident for this issue and will contact you using that channel.
Thank you,
Hi,
In that case it is not as straightforward.
Maybe you could disable the foreign key and only enable it once the manual data changes have been made?
If that's not an option here's something else you can try:
- Add a table named Group, add GroupId column to User table and related that column with Id column in Group table. Don't drop RoleId column. GroupId column might need to be nullable here.
- Deploy these changes.
- Handle necessary data changes manually for User table to relate the users with Groups now and add data to Groups table, too.
- In dev, drop the RoleId column in User table.
- Deploy the changes.
- Now, you can try to make the GroupId column not nullable and deploy this change.
Thank you, / comments
Hi,
In that case it is not as straightforward.
Maybe you could disable the foreign key and only enable it once the manual data changes have been made?
If that's not an option here's something else ...
Hi,
I've been testing this and in this case the way to go would be to create a deployment script, unfortunately there isn't a switch that would allow you to ignore this.
Thank you, / comments
Hi,
I've been testing this and in this case the way to go would be to create a deployment script, unfortunately there isn't a switch that would allow you to ignore this.
Thank you,