Comments
2 comments
-
Hello,
Just to note, SQL Source Control is still in an early access phase and we do not recommend using it on Production DBs.
Your situation is kind of unique since you do not have a dev db...
I don't understand exactly what you are trying to do. :-) It sounds like you are using Visual Studio and editing the CREATE script files directly. The whole purpose of SQL Source Control is that you can continue to work directly on your db within SQL Server Management Studio, so that you don't have to worry about the CREATE scripts and SQL Source Control generates them for you. If you do make a change in VS and commit it, then you should see this on the Get Latest tab and you can click the "Get Latest" button to update the db. What do you mean that you cannot "Get Latest?" Please be careful that the SQL syntax within the script is correct. This is why it is better to just work directly on the db.
It's true that changes to the db do not automatically get committed to source control. This requires discipline from the db developer to commit the change. We would like them to supply a comment when commiting so others can understand why they made the change. SQL Source Control helps by placing blue indicators on the ObjExp, which reminds you that you have made changes that you haven't commited yet.
You can use SQL Compare Pro to automatically check that your production db is at the version you expect it to be. This is retroactive, but allows you to see if any changes are made directly to prod that were not expected. These changes can then be applied back to your dev db and committed to source control if that's what is decided.
I hope this helps! Please let me know if you are still having problems getting changes from TFS to your db.
Thank you!
Stephanie M. Herr :-)
SQL Source Control - Project Manager -
Good morning
Thanks. To try to clarify what I am attempting to do:
1) I am looking to establish a source control system - not only no dev environment but no source control either.
One reason for this is to overcome the problem of senior management "modifying" code in the DB without reference to other users or security or data integrity etc. Changing their access is not an option, so enforcing some Source Control may slow them down. I would hope it gives the option of replacing the code in the DB with what is in source Control.
2) It is possible that other developers within the organisation may choose to modify some code and they may use Visual Studio for this rather than Management Studio.
I was trying to see what the results were when this occurred. I found I could check out edit save checkin/commit etc from VS but I could not "deploy" those changes to the DB. When clicking the Get Latest button to update the DB I received advice that there was nothing to Update. It appeared as though the DB was held to be the source of all truth and while I could see the differences between the 2 files I only had the option to Commit the DB version rather than get the latest version.
Does that make it any clearer?
And the good news is I might be closer to getting a dev system now!
Add comment
Please sign in to leave a comment.
I want to be able to replace any code (authorised or not) in the DB with what exists in TFS and if the version in the DB always overrules the TFS source Control version I am lost.
I have linked the production DB in question into TFS, the source control folders are populated with the stored proc's etc, all is fine there.
I have had to modify an existing Sp in prod. This was checked out, mods done and tested, changes applied to existing SP, file checked in through the Commit. All looking good.
If I want to edit it through VS however, any changes are recorded and the file is checked in but while a difference is noted, I cannot 'Get Latest ' from TFS to SSMS. I am assured there are no changes. Hence if any changes are made in the DB and not Committed, I may not be able to undo them. What have I done wrong (apart from the lack of a dev environment :roll: )
Thanks