DEFECT: 3.0.11.3531 - Table Rename not recognized

PDinCA

Having just run "Smart Rename" on two tables in the same database, refreshed the Tables node in SSMS and hit Ctrl+Shift+D and seen SQL Prompt refresh my suggestions list, I was appalled to see no change to the database icon signifying a pending source code change.

Initiating the SSC "Commit Changes to Source Control..." on the database I was informed I had no changes to commit!

Clearly a DEFECT.

Please advise.

UPDATE:
Having completed all renames on the database in question, the behavior remains as above. However, forcing a "Refresh" on the SSC dialog evidences all my renames. Sadly, they are all DROP - NEW actions, rather than SVN renames.

Is there any way to have SSC rename the objects in SVN, please? I have NOT run the COMMIT.

csmith

Hi

In version 3 of SQL Source Control we added the Migration Scripts feature to handle this and other scenarios that could cause data loss (see this post on our feedback site).

The feature allows users to add a custom upgrade script around a change (or changes) in order to override default comparison/deployment behaviour. For more information about Migrations, please visit: http://www.red-gate.com/supportcenter/Content/SQL_Source_Control/help/3.0/SSC_Working_With_Migrations.

Best regards,
Chris

PDinCA

Perhaps I miscommunicated, Chris. I SHOULD have said that the rename was a TABLE rename, not a column or anything else rename.

There's no question of any data loss whatsoever.

This is a table rename, pure and simple. Custom migration scripts are in no way necessary and it would be a complete waste of my time to develop one.

The objective is ONLY "I want to rename the object in SVN having renamed it in the database".

Would that an sp_rename on a table were detected by SSC and handled as an SVN rename! Would an extended event facilitate this?

Perhaps in view of the revised information you could re-read the post and respond with something that may address the actual situation - that would help a lot. Thanks.

csmith

Hi

Thanks for your post. I did realise that you were renaming a table but I was focussing on deploying & sharing these changes, in which case Migration Scripts are how we'd recommend you handle the issue.

In terms of underlying filename in the repository, which I think is your concern, we do not attempt to perform an SVN rename on a file because we have not identified the rename operation. This is because in order to determine what appears on SQL Source Control's commit tab the application performs a comparison between the state of the sql files in your repository and the live database you are developing against. Unfortunately, this comparison cannot automatically tell the difference between a user dropping a table & adding a new table, and a user renaming a table.

I understand your frustration that this is not an automatic process. We plan to enhance the comparison logic in the future to recognise a rename (perhaps by comparing Object IDs, or column similarities), but I cannot give you a date for when that work would be completed. In the meantime, you could add a migration script around the commit, including the appropriate sp_rename calls.

Committing a 'table drop' and a 'table add' to the repository becomes a problem when it is time to deploy changes from a repository into a test, staging or production environment using SQL Compare, or when another user of SQL Source Control performs a 'Get Latest' operation. This is because any data in the table will be lost when it is dropped and re-added. This is one of the reasons we added the Migration Scripts feature.

If you'd like any more help with the Migrations feature, please let me know or email support@red-gate.com.

Best regards,
Chris

PDinCA

Thanks for the detailed explanation, Chris, it helps to understand the bigger picture on our end.

I used SQL Multi Script to deploy all the renames simultaneously across all our servers. Thankfully these are all audit-tables with only one of them being referenced by anything other than a data-change trigger. The only reason for renaming is due to SQL Prompt's inability to always show the schema in the suggestions list by default, and with identical table names, albeit with dbo and z_audit schema, I was tired of the wait for an enhancement and decided to make all the table names unique to reduce the noise in SQL Prompt.

I look forward to the continued improvements with SSC. Having endured 6 years of SQL Server with TFS not integrated into SSMS, SSC, despite some shortcomings, is now indispensable, non-invasive and, for our relatively small db-count and object-count site, very simple to operate. KISS works well for us!

Thanks again,

Regards,

Stephen