Comments
Sort by recent activity
Please vote/comment on this feature for SQL Source Control on our Suggestion Forum at http://redgate.uservoice.com/forums/390 ... ?ref=title / comments
Please vote/comment on this feature for SQL Source Control on our Suggestion Forum at http://redgate.uservoice.com/forums/390 ... ?ref=title
Emailed user directly to try and get a better understanding of what steps to take so we can try and reproduce this issue. / comments
Emailed user directly to try and get a better understanding of what steps to take so we can try and reproduce this issue.
Hi Graham,
Thanks for letting us know about this issue. We currently do NOT notify you if you rename a Primary Key. We will notify you if you alter a table and add a PK or drop a PK.
As soon as you go to the Commit list, we'll realize there is a change and put a blue indicator on the table.
David is right. We don't put blue indicators on nodes lower than the actual table. This is because the columns, keys, indexes, etc. get scripted in the same file as the CREATE TABLE script, which is in the Tables directory in source control.
Our internal issue number is SOC-816. / comments
Hi Graham,
Thanks for letting us know about this issue. We currently do NOT notify you if you rename a Primary Key. We will notify you if you alter a table and add a PK or drop a PK.
As soon as y...
Oops! You're right. I meant RC. I updated our internal issue to reflect this. :-) Thank you! / comments
Oops! You're right. I meant RC. I updated our internal issue to reflect this. :-) Thank you!
We are currently supporting TFS 2008. (There is minimal support for TFS 2005, but this hasn't been tested completely since most users seem to be on 2008.) So, SQL Source Control is looking for either the Team Explorer 2005 or 2008 Client.
We haven't tested against Visual Studio 2010 yet since that is still in beta, but we do plan to support that. Our internal issue reference number is SOC-804.
Thanks for providing us with the link to the blog! / comments
We are currently supporting TFS 2008. (There is minimal support for TFS 2005, but this hasn't been tested completely since most users seem to be on 2008.) So, SQL Source Control is looking for ei...
Hello Jim,
Any information you could provide would be extremely valuable especially the SQL Compare script showing the differences between the databases.
Would it also be possible to send the scripts for the actual objects that are different if there are not too many? It would be helpful if you could include the db version and the source control version. Or would sending snapshots of your database and the source control version be possible? (You can create snapshots using SQL Compare, select DB as source and Snapshot as target, then create a new snapshot. Link a new empty db to the same source control and get latest. Then snapshot this db as the source control version.)
Please send this information to SqlSourceControlSupport@red-gate.com. If you zip up the information, please rename the zip as .zip.txt so that it passes our security check.
Thank you!
Stephanie Herr :-) / comments
Hello Jim,
Any information you could provide would be extremely valuable especially the SQL Compare script showing the differences between the databases.
Would it also be possible to send the scrip...
Hi Jason54,
Thanks for reporting this issue.
The "Failed to locate the target table" is a known issue. We think it's because there are slight changes between the db and the repo and we're not sure which version you are at. The best thing to do for now is to create a new db and link that and then pull the latest from source control into that new db, if that is possible. I realize this means your new db won't have the data from your existing db...
We are working on fixing this FK Issue though. Our internal reference number is SOC-803.
There are some known issues if you have different db versions that are attached to the same repo. Things like using a SQL 2008 datatype and committing to a repo which a SQL 2005 db pulls from would fail. I don't think this is the issue in this case, but I just wanted to make sure you were aware of this. Also, we do not official support Express Editions. We don't load in SS 2005 Express at all.
Thank you!
Stephanie M. Herr :-) / comments
Hi Jason54,
Thanks for reporting this issue.
The "Failed to locate the target table" is a known issue. We think it's because there are slight changes between the db and the repo and we're not sure...
This is definitely not good in the long run, but I'm glad you're able to use SQL Source Control against your development db for now. We don't recommend using SQL Source Control with your live/production database because SQL Source Control is more for your day to day db development and committing these changes to source control so there is a history of every change along with who made the change, when, and why. When it comes time to push your changes to your other environments (test, QA, staging, production), then you can use SQL Compare Pro to generate the synchronization script to bring your target database up to date. There is a 14 day free trial of SQL Compare on our web site at http://www.red-gate.com/products/SQL_Compare.
There are some known issues of linking a database to source control if it doesn't match exactly. Do you know how your development db differed from your live/production db? Did one of the tables in the FK relationship match live/production exaclty and the other one have a slight change?
Our internal reference number for this issue is SOC-803. / comments
This is definitely not good in the long run, but I'm glad you're able to use SQL Source Control against your development db for now. We don't recommend using SQL Source Control with your live/prod...
Thanks for sending in the error report and posting this issue here.
I think you see an error like "Nothing to Commit" because the dbo schema shows up on the Commit list, but then it doesn't actually recognize this change so it thinks there is nothing to commit.
We are currently working this issue. Our internal reference number is SOC-799.
For now, please just ignore this on your commit list. If there are multiple objects to commit, it will NOT error because there will be something else to commit.
There is a manual workaround if you want to get this object off your commit list and you don't expect it to change much. (If it changes a lot, you'll have to re-do this workaround each time.) Workaround: Manually create the schema file if you are familiar with TSVN:
1. Check out the repository to a working folder (You can right-click on the URL on the Setup Tab and copy it.)
2. In the Security\Schemas directory, create a text file and rename it to dbo.sql
3. Paste in the text from the db version diff pane on the Commit Tab (You can right-click on the diff pane Select All, right-click again and copy.)
This was:
-- Permissions
GRANT VIEW DEFINITION ON SCHEMA:: [dbo] TO [cy_reader]
GO
4. Remove the "-- Permissions" and the empty line from the top of the file
5. Save the file
6. Use TSVN to Add and Commit this change back to the repository
7. In SSMS, refresh your commit list
The dbo schema should no longer appear on the commit list. / comments
Thanks for sending in the error report and posting this issue here.
I think you see an error like "Nothing to Commit" because the dbo schema shows up on the Commit list, but then it doesn't actuall...
Thanks for letting us know how you fixed it. The 3 places you mentioned make sense. I'll add this workaround to your issue and we'll see if there's a way we could prevent it from having this problem in the first place. / comments
Thanks for letting us know how you fixed it. The 3 places you mentioned make sense. I'll add this workaround to your issue and we'll see if there's a way we could prevent it from having this prob...