Add support for External Tables
I use Azure SQL, and there is limited cross-database functionality in that environment. Due to this I have several External Tables that I use to point to a Master Database with shared setting, info, etc. for each customer database.
When I used SQL Compare to fill out the schema for a new database it copied all of the External Tables as Local Tables, and it didn't bring over the Data Source either. This could be very handy as dealing with external tables (and especially changes to them) is a pain.
We shipped support for External Tables in SQL Compare 14.5.
Please turn on frequent updates to get this version
For more information, see the release notes:
David Siclari commented
Version 14.5 for SQL Compare is not yet available in the Free-Trial download. When will this be available ?
Richard Swindells commented
This is an issue for me too, currently evaluating a switch from Devart tools to Redgate. We use external tables extensively in Azure SQL (NOT DWH) and this is a potential show-stopper for us, to see how long ago this was first requested and still not implimented as a standatd feature.
Tyler Spellen commented
I have just ran into a similar issue as well related to trying to use the "Get Latest" functionality within SQL Source Control, and the external tables and external resources SQL scripts failed on trying to register with SQL Source Control. So could use that functionality as well.
Scott Wallace commented
This is a needed feature. Visual Studio 2019's db compare can detect them, so I can't imagine this is a big deal to add support for External Tables.
This became such an issue with us when we were rolling out a publish to change one table from a normal table to an external table. It kept trying to automap columns and preserve the data, which was totally incorrect, since the table needed to be dropped and recreated. Because any local data was no longer needed. And it's not an issue right this moment, but in the future any dependencies between external tables and other objects will surely be a pain to roll out (especially since you can't cherry pick dependencies to deploy)
Ron Michael Zettlemoyer commented
A first step would be if it at least recognized it as an external table - treated it as a separate object type - and didn't generate scripts to create it as a local table.