Blog Post

Azure Database Support Blog
3 MIN READ

Lesson Learned #225: Has an unresolved reference to object using Linked Server or External Table

Jose_Manuel_Jurado's avatar
Jul 17, 2022

We used to have cases when our customers are trying to export their database using SQLPackage or Export service in the Portal having, for example, the following error message: Error SQL71562: Error validating element Synonym: [dbo].[MyView] has an unresolved reference to object [linkedserver].[databasename].[schemaname].[tablename]. External references are not supported when creating a package from this platform. In this post I would like to suggest an alternative to export this data.

 

The first thing that we need to know that SQLPackage validates that we don't have any of the following points in our database that we want to export:

 

  • Reference using 4 parts, for example, databasename.schemaname.tablename
  • Using an external table.
  • Calling a table using a linked server, for example, select * from mylinkedserver.databasename.schema.table
  • Calling a synonyms that uses a linked server, for example, CREATE SYNONYM [dbo].[ExternalTable1] FOR [linkedserver].[databasename].[schemaname].[tablename]

If we have any of these scenarios we are going to have the following error message exporting the data:

 

  • One or more unsupported elements were found in the schema used as part of a data package.
    Error SQL71562: Error validating element Synonym: [dbo].[MyView] has an unresolved reference to object [linkedserver].[databasename].[schemaname].[tablename]. External references are not supported when creating a package from this platform.

  • One or more unsupported elements were found in the schema used as part of a data package.
    Error SQL71562: Error validating element [dbo].[ExternalTable1]: Synonym: [dbo].[ExternalTable1] has an unresolved reference to object [linkedservername].[databasename].[schemaname].[tablename]. External references are not supported when creating a package from this platform.

 

In order to be able to export the data, I developed the following stored procedure that basically, runs the following code. The goal is to create dynamically the external table and/or view or synonym that is calling external tables,

 

  • Parameters:
    • @TableName = will be the name of the synonym or external table to create. 
    • @Action = will be the operation to perform, CREATE or DROP the synonym

 

 

 

CREATE PROCEDURE dbo.DeployMyExternalTable(@TableName varchar(400),@Action VARCHAR(10))
AS

 IF @TableName = 'ExternalTable1' 
 BEGIN
  IF @Action = 'CREATE' 
    BEGIN 
      IF NOT EXISTS( SELECT TOP 1 NAME FROM SYS.synonyms WHERE Name='ExternalTable1' )
	  	 EXEC SP_EXECUTESQL N'CREATE SYNONYM [dbo].[ExternalTable1] FOR [LinkedServerName].[DatabaseName].[SchemaName].[ExternalData1]' 
    END
  IF @Action = 'DROP' 
    BEGIN 
	 IF EXISTS( SELECT TOP 1 NAME FROM SYS.synonyms WHERE Name='ExternalTable1' )
	    EXEC SP_EXECUTESQL N'DROP SYNONYM [dbo].[ExternalTable1]' 
    END
 END
 
 IF @TableName = 'ExternalTable2' 
 BEGIN
  IF @Action = 'CREATE' 
    BEGIN 
     IF NOT EXISTS( SELECT TOP 1 NAME FROM SYS.synonyms WHERE Name='ExternalTable2' )
    	 EXEC SP_EXECUTESQL N'CREATE SYNONYM [dbo].[ExternalTable2] FOR [LinkedServerName].[DatabaseName].[SchemaName].[ExternalData2]' 
    END
  IF @Action = 'DROP' 
    BEGIN 
	 IF EXISTS( SELECT TOP 1 NAME FROM SYS.synonyms WHERE Name='ExternalTable2' )
	    EXEC SP_EXECUTESQL N'DROP SYNONYM [dbo].[ExternalTable2]' 
    END
 END

 

 

 

The idea is if you need to run any query against this synonym or external table is to run the following code: 

 

 

 

exec dbo.DeployMyExternalTable 'ExternalTable1', 'CREATE'

SELECT * FROM [dbo].[ExternalTable1]

 

 

 

Or if you need to delete it

 

 

 

exec dbo.DeployMyExternalTable 'ExternalTable1', 'DROP'

 

 

 

Basically, if you need to export the data, you could call these stored procedure for all synonyms or external tables, export the data and after it your application/database will create again them without modifying your code. 

 

Enjoy!

Updated Jul 21, 2022
Version 4.0
  • EitanBlumin's avatar
    EitanBlumin
    Brass Contributor

    What if there are internal dependencies on such synonyms?

    Wouldn't dropping them break the verification as well?

    And let's say that instead of dropping synonyms, you'd "redirect" them towards an internal table or object.

    But then, wouldn't it still cause verification errors if there are dependencies that rely on a specific table/column structure?

    Not to mention the obvious impact on business logic during production.

     

    Here's a big idea for the Microsoft team which should make this much simpler:

    Add support for the "VerifyExtraction=False" parameter for the "Export" action as well and not just the "Extract" action.

     

    P.S.

    You also have a syntax error here (CREATE SYNONYM written twice):

        	 EXEC SP_EXECUTESQL N'CREATE SYNONYM [dbo].[ExternalTable2] CREATE SYNONYM [dbo].[ExternalTable2] FOR [LinkedServerName].[DatabaseName].[SchemaName].[ExternalData2]' 

     

    Generally, I'd expect a better solution than hard-coding the creation code per each individual synonym.
    Why not use the metadata in sys.synonyms to auto-generate the creation code for all 3-part-name and 4-part-name synonyms in advance?

  • Thanks EitanBlumin for your feedback. It's great to have these ideas and suggestions to improve our products and first of all, my apologies for my mistake about the syntax, I already fixed it. 

     

    As we cannot consider use SqlPackage or Export/Import service as a backup mechanism, the best practice is to perform a database restore using PITR at the moment that you want to export.

     

    Being said this, the next step, when you have this database restored, is to proceed with the deletion of these unresolve references calling DeployMyExternalTable stored procedure to delete all the synonyms or external tables including the references (for, example, views), export the data and after it recreate again this if needed.

     

    I used synonyms as an example and I agree with you about the idea to include the option for the "VerifyExtraction=False" parameter for the "Export" action as well and not just the "Extract"  action, our Azure Product Team is aware about it and I would like to suggest if you could add this idea in our feedback website  we have others about the topic of Export/Import.  I submitted this feedback internally to our Azure Product Team.

     

     

    Meanwhile, the main idea to export the data without receiving this error currently, having in just only place of this logic. All this feedback is very welcome, please, continue this discussion adding your ideas or suggestions about this topic, I'm sure that your experience could help the community. 

     

    Thanks again!