Skip to content
← SQL Compare

How can we improve SQL Compare?

SQL Compare

Categories

JUMP TO ANOTHER FORUM

(thinking…)

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.

119 votes
Vote

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
You have left! (?) (thinking…)
Will shared this idea  ·   ·  Report…  ·  Admin →

We're glad you're here

Please sign in to leave feedback
Signed in as (Sign out)
Close
Close
Submitting...
An error occurred while saving the comment
  • David Siclari commented  ·   ·  Report

    Version 14.5 for SQL Compare is not yet available in the Free-Trial download. When will this be available ?

  • Richard Swindells commented  ·   ·  Report

    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  ·   ·  Report

    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  ·   ·  Report

    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.

  • AJ commented  ·   ·  Report

    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  ·   ·  Report

    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.