¿Es posible crear una tabla temporal en un server vinculado?

Estoy haciendo algunas consultas bastante complejas contra un server vinculado remoto, y sería útil poder almacenar cierta información en tablas temporales y luego realizar uniones contra ella, todo con los datos remotos. Crear las tablas temporales localmente y unirlas contra ellos a través del cable es prohibitivamente lento.

¿Es posible forzar que se cree la tabla temporal en el server remoto? Supongamos que no tengo suficientes privilegios para crear mis propias tablas reales (permanentes).

No es posible crear directamente tablas temporales en un server remoto vinculado. De hecho, no puede usar ningún DDL contra un server vinculado.

Para get más información sobre las directrices y limitaciones de uso de serveres vinculados, consulte:

Directrices para usar consultas distribuidas (SQL 2008 Books Online)

Una alternativa (y fuera de mi cabeza, y esto solo funcionaría si tuviera permissions en el server remoto) podría:

  • en el server remoto tienen un procedimiento almacenado que crearía una tabla persistente, con un nombre basado en un parámetro IN
  • el procedimiento almacenado remoto ejecutaría una consulta y luego insertía los resultados en esta tabla
  • A continuación, realiza una consulta local contra esa tabla para realizar cualquier unión a cualquier tabla local requerida
  • Llamar a otro procedimiento almacenado en el server remoto para soltar la tabla remota cuando haya terminado

No es ideal, pero es posible que funcione.

Esto funciona desde SQL 2005 SP3 vinculado a SQL 2005 SP3 en mi entorno. Sin embargo, si inspecciona el tempdb, encontrará que la tabla está realmente en la instancia local y no en la instancia remota. He visto esto como una resolución en otros foros y quería alejarte de esto.

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

Sí, puedes, pero solo dura la duración de la connection. Debe usar la syntax EXECUTE AT;

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

En SERVER2, lo siguiente funcionará (durante 1 minuto);

 SELECT * FROM ##example 

pero no funcionará en el server local. Incidentemente, si abre una transacción en el segundo server que usa ## ejemplo, el object permanece hasta que la transacción se cierre. También evita que se complete la statement de creación en el primer server. es decir, en server2 run y la transacción en server1 continuará indefinidamente.

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

¡Esto es más académico que de uso práctico!

Si la memory no es un gran problema, también podría usar variables de tabla como alternativa a las tablas temporales. Esto funcionó para mí al ejecutar un procedimiento almacenado con la necesidad de almacenamiento temporal de datos contra un server vinculado.

Más información: por ejemplo, esta comparación de variables de tabla y tablas temporales, incluidos los inconvenientes de usar variables de tabla.

Llego 2 años tarde a la fiesta, pero puede lograrlo utilizando sp_executeSQL y sp_executeSQL una consulta dinámica para crear la tabla de forma remota.

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

Esto ejecutará la creación de la tabla temporal en la location remota.