8

I'm doing some fairly complex queries against a remote linked server, and it would be useful to be able to store some information in temp tables and then perform joins against it - all with the remote data. Creating the temp tables locally and joining against them over the wire is prohibitively slow.

Is it possible to force the temp table to be created on the remote server? Assume I don't have sufficient privileges to create my own real (permanent) tables.

Herb Caudill
  • 50,043
  • 39
  • 124
  • 173

5 Answers5

5

This works from SQL 2005 SP3 linked to SQL 2005 SP3 in my environment. However if you inspect the tempdb you will find that the table is actually on the local instance and not the remote instance. I have seen this as a resolution on other forums and wanted to steer you away from this.

create table SecondServer.#doll
(
  name varchar(128)
)
GO
insert SecondServer.#Doll
select name from sys.objects where type = 'u'


select * from SecondServer.#Doll
doug_w
  • 1,330
  • 10
  • 10
3

I am 2 years late to the party but you can accomplish this using sp_executeSQL and feeding it a dynamic query to create the table remotely.

Exec RemoteServer.RemoteDatabase.RemoteSchema.SP_ExecuteSQL N'Create Table here'

This will execute the temp table creation at the remote location..

PaulStock
  • 11,053
  • 9
  • 49
  • 52
Korey
  • 31
  • 1
2

It's not possible to directly create temporary tables on a linked remote server. In fact you can't use any DDL against a linked server.

For more info on the guidelines and limitations of using linked servers see:

Guidelines for Using Distributed Queries (SQL 2008 Books Online)

One work around (and off the top of my head, and this would only work if you had permissions on the remote server) you could:

  • on the remote server have a stored procedure that would create a persistent table, with a name based on an IN parameter
  • the remote stored procedure would run a query then insert the results into this table
  • You then query locally against that table perform any joins to any local tables required
  • Call another stored procedure on the remote server to drop the remote table when you're done

Not ideal, but a possible work around.

Kev
  • 118,037
  • 53
  • 300
  • 385
2

Yes you can but it only lasts for the duration of the connection. You need to use the EXECUTE AT syntax;

EXECUTE('SELECT * INTO ##example FROM sys.objects; WAITFOR DELAY ''00:01:00''') AT [SERVER2]

On SERVER2 the following will work (for 1 minute);

SELECT * FROM ##example

but it will not work on the local server. Incidently if you open a transaction on the second server that uses ##example the object remains until the transaction is closed. It also stops the creating statement on the first server from completing. i.e. on server2 run and the transaction on server1 will continue indefinately.

BEGIN TRAN
SELECT * FROM ##example WITH (TABLOCKX)

This is more accademic than of practical use!

Stuart
  • 21
  • 2
1

If memory is not much of an issue, you could also use table variables as an alternative to temporary tables. This worked for me when running a stored procedure with need of temporary data storage against a Linked Server.

More info: eg this comparison of table variables and temporary tables, including drawbacks of using table variables.

Josien
  • 13,079
  • 5
  • 36
  • 53
  • The drawback to this is that, as far as I know, you can't create indexes on table variables. (I'm 2 years late, I know...) – alfoks May 31 '13 at 09:57
  • 2
    It seems you can [create indexes on table variables](http://sqlserverplanet.com/tsql/create-index-on-table-variable). (Didn't know that either!) – Josien May 31 '13 at 10:27
  • Great! Thanks for sharing. I'll have it in mind in the future. – alfoks Jun 02 '13 at 20:06
  • Unfortunately, I don't believe this works for linked servers -- at least not with execute-at. – Kaganar Aug 24 '13 at 15:46