SQL Source Control not seeing file already exists

SeanRhone

I have set up a project in TFS using the plugin in SSMS and everything was working fine, the problem seems to happen when someone added a new stored procedure to the database without using sql source control or sql compare. In TFS I see the stored procedure checked in but when I run sql source control it shows the stored procedure as new and not in TFS.

I have tried everything I can think of
1) Use the "Get latest" tab
2) Unlinked the databases and deleted the folders under the Redgate (Transients-TFS, WorkingBases) and relink

So, how do I get SQL Source Control to see the files that DO exists in TFS?

Chris Auckland

Thanks for your post.

Are you using the shared or the dedicated development model with SQL Source Control?

If you're using the shared model then there isn't really a concept of 'get latest' as the database will always be up-to-date.

If you're using the dedicated model, then if the files are committed to the same TFS repository, then a 'get latest' should pull them down.

SeanRhone

We are using the Shared model

Chris Auckland

That doesn't sound right.

What happens if you try to commit the object that's already been added to TFS? Does the blue indicator go away, or does it throw an error?

SeanRhone

When I commit the file (showing as new) in does commit the file then blows up with an error about same stored procedure in multiple files (my language but close in meaning).

When I look at TFS afterwards I now have two files the original stored procedure I merged up from the development branch and a new one name "procname1"; so what happened is it committed the file and just append a "1" to the file name.

Chris Auckland

What's the process for adding the object outside of SQL Source Control?

Is the file being directly added to TFS, or is it added to the shared database first and then added to TFS manually?

I don't think the shared model will check what's already in TFS as a shared database will always be on the latest version.

If the object is added to the shared database first and then added to TFS then I would think it *shouldn't* show the item as new.

I can test it out if that isn't the case.

SeanRhone

The process is
1) Developer creates a new stored procedure using SSMS (no Redgate tools)
2) They test / QA etc then check the file into TFS (our development branch)
3) They execute the script in the Shared database using SSMS (again no Redgate tools)
4) I then migrate changes from the development TFS branch up to QA then production. The production branch is what is linked to the Redgate SQL source control.
5) I then use the Redgate tools to make sure everything is in sync.

SeanRhone

Okay, so to try and fix the issue of the stored procedure being in TFS and run in the shared production database (outside of Redgate tools) I deleted the proc in TFS and committed the change from sql source control, I then checked the file out in TFS and altered the contents with the updated logic and then I used SQL Compare to compare TFS to the shared database hoping I could generate a script and it still does not see the script being in TFS. If I edit the project and select "Version: <Select a version from history...> it does find the change but if I leave "Version: Latest (Head)" it does not see it.

very frustraiting!

SeanRhone

Okay, while it seeing the difference in the "History" popup it still does not show the proc being in TFS - It shows as only in the shared database.

Chris Auckland

What does the file look like in Team Explorer? Are there any 'Pending Changes' to check in? SQL Source Control will only see the checked in files.