Feature request: Sort objects in deployment script

Chris_F

When generating the sql compare deployment script - all objects are scripted in a seemingly random order.

This could be covered by an option to enable/disable it.

And obviously, there is a dependency order which much take priority first. But after that all objects should be scripted in alphabetical order.

Use case for this is generating the same update script multiple times and committing it to source control. If this is done during a RC phase, the later iterations of the script will be 90% the same with minimal differences.

Currently as it stands, objects get moved around in the output script, so when comparing scripts you cant actually tell what the true changes are - they could be identical. To diff the script you need to cut out the moved object and paste it in the old location.

Also any manual changes to the script will be difficult to identify in future scripts as well.

Sergio R

Thank you for your suggestion. Would you be able to post it on our dedicated forum for feature requests?
https://redgate.uservoice.com/forums/141379-sql-compare

The main reason why object creation\change is not deterministic in the deployment scripts is due to performance.

On the other hand, our best practices when using SQL Compare with Source Control, involve using SQL Source Control which source control object script files (representing the current state of the database) and not deployment scripts.

I would also like to recommend you to try another of our tools: SQL Change Automation, which is migration based and would allow you to source control migration scrips and then seamlessly deploy them. Until recently SQL Change Automation was a Visual Studio plugin only, however we now have an SSMS version in beta: https://www.red-gate.com/products/sql-development/sql-change-automation/entrypage/ssms-addin 

Chris_F

Hi,

I have added to the uservoice site, also thanks for your suggestion of your other tools too.

The main reason for my particular use case is that the deployments are often done by clients where we have no access to their database, network or even direct contact with their sql engineers. It's completely hands-off. Also there is some data manipulation done as well.

This leads us to having release cycles where code changes and database changes are scripted into our source control as part of the release process.