I have two SQL Servers (running SQL Server 2008) named DATA01 and DATA02. DATA02 has a linked server definition LINK, that points at DATA01, with suitable user mapping set up. On DATA01 there is a database MyDatabase containing these two tables:
CREATE TABLE T_A (
Id int
)
CREATE TABLE T_B (
Id int,
Stuff xml
)
When I run this command from DATA02, I get data returned as expected:
SELECT Id FROM LINK.MyDatabase.dbo.T_A;
However, when I run this command from DATA02, I get an error:
SELECT Id, Stuff FROM LINK.MyDatabase.dbo.T_B;
The error is
Xml data type is not supported in distributed queries. Remote object ‘DATA02.MyDatabase.dbo.T_B’ has xml column(s).
And strangely, this command:
SELECT Id FROM LINK.MyDatabase.dbo.T_B;
also gives the same error, even though I’m not SELECTing the xml column! What’s going on?
This is a deficiency within SQL Server. The mere existence of an xml column on the table prevents it from participating in distributed queries (eg being queried through a linked server connection). This is mentioned in this ‘retired’ documentation. There doesn’t appear to be any mention of this in the current version’s documentation.
There used to be relevant bug reports on Microsoft Connect, but that’s now been ‘retired’ in favour of the Azure feedback forums. This feedback item is Closed with an instruction to "Please submit feedback directly from the product documentation", which would be fine if the product documentation actually mentioned this. This other feedback item includes commentary migrated from Connect, and has the status ‘Unplanned’.
One of the Connect bug reports that used to exist gave two workarounds:
In your example, this would involve adding a view to
MyDatabasethat looks like this:
You could then query this view through the link to get the
Iddata. Note that something like
doesn’t work.
This method has the advantage of not requiring any change to the
source database; the downside is that it is no longer possible to
use standard four-part naming for both local and linked data. The
query would look like
Note that if you actually do want the xml data, this method (along
with casting to and from a non-xml datatype) will be required :
Note that the bug was first reported in SQL Server 2005, and remains unfixed in SQL Server 2017. I haven’t yet been able to check SQL Server 2019.