Dropped Tables Not Showing In Get Latest Changes

BrentS

Hello everyone!

I'm currently running into an issue with SQL Source Control and Git and could use some help.

One of my team members made a change to our database by dropping a table through SSMS. When going to commit these changes in SQL Source Control, everything is fine and they are able to see and commit the drop. We also verified the table is no longer apart of the schema in his Git branch. He pushes that branch to the remote repository and its ready for me to pull down and put into my database.

The issue happens when I clone the repository, check out his branch, and link it to my database. When I go to "Get Latest" its not showing me any option to drop the table from my own database. Shouldn't SQL Source control recognize that the table no longer exists in the schema in source control and show me a drop option for the table that still exists in my database?

I've cleared out all filtering options (I didn't have any to begin with) and made sure no comparison options were enabled that could cause this behavior.  Any support is greatly appreciated!

Kurt_M

Hi @BrentS

I've tried to replicate this on my own environment and I think I might have done it. Can I get you to confirm whether you have the dropped table coming up in the 'Commit' tab?

My dropped table does not appear in the 'Get Latest', but it does appear in the 'Commit. This would be because the transient folder (which is a copy of the head revision in the version control system) and the working base folders match, and therefore don't have any differences. 

The reason it would be coming up in the 'Commit' tab is because it's detecting it as a new change, due to the recent linking of the version control system schema. 

BrentS

Thank you for your response @Kurt_M ! 

Let me try and provide the scenario more clearly:

1. My team member has a new feature to work on that requires a table drop. We'll call this feature A and the table TableA.
2. They clone the master branch from the remote repository and checkout a new feature branch feature/A.
3. They link feature/A to their database via RedGate SSC
4. They run a script to drop TableA from SSMS.
5. When they go to Commit this change to feature/A they are able to see a change type of Drop for TableA. They commit the drop or TableA to feature/A and push feature/A to the remote.

Now I come along and need to take their change from feature/A:

1. I clone the master branch from the remote repository
2. Checkout branch feature/A
3. Link feature/A to my database (I still have TableA in my database)
4. Go to the "Get Latest" tab
5. No Drop change type exists for TableA

My thought would be in linking feature/A to my database and looking at Get Latest it would see that I have a table in SSMS that no longer exists in feature/A and would put this in the Get Latest list for a drop change type.

This feels like it would be a pretty common scenario for any development team so I'm left wondering if there is something fundamental about SSC that I'm missing here...

Kurt_M

Hi @BrentS

Thanks for providing that information. A lot of the steps you provided are essentially how I tested it on my internal system.

I also checked with a colleague on this, so that I could provide you with accurate information.

Unfortunately, it's like I originally explained it. If the linking is happening after the update to the source control system, then SSC is not going to see the dropped table as a drop command in the 'Get Latest' tab. It instead shows it as a new table in the 'Commit' tab.

The best practice would be to either link the newly cloned repo to an empty database or synch the existing database beforehand.

To work around this issue you can unlink the database sync it using SQL Compare and then re-link it.