Ir al contenido principal

¿Cómo ejecutar consultas dinámicas sobre OPENROWSET o sobre Servidores Vinculados (OPENQUERY)?

Una limitación al utilizar OPENROWSET u OPENQUERY en SQL Server es que no es posible utilizar variables para especificar los datos de conexión o la consulta (SQL o MDX) que se desea ejecutar. Entonces, al ejecutar consultas AdHoc con SQL Server (ya sea con OPENROWSET o con OPENQUERY) ¿Cómo especificar de forma variable o dinámica los datos de conexión? ¿Cómo especificar de forma variable o dinámica la consulta a ejecutar?. Esta funcionalidad que en ciertas ocasiones puede resultar muy-muy apetecible, es fácilmente remediable utilizando SQL Dinámico (ya sabemos, que el SQL Dinámico es una de esas funcionalidades tan queridas como odiadas entre los profesionales de SQL Server).

Como ejemplo vamos a tomar el caso de OPENROWSET, aunque con OPENQUERY sería el mismo razonamiento. El escenario es el siguiente: ejecutar una consulta de SQL Dinámico, la cual utilice OPENROWSET u OPENQUERY, de tal modo que dicha consulta de SQL Dinámico será una simple variable de tipo VARCHAR o NVARCHAR (recordar que sp_executesql require NVARCHAR), sobre la cual si podremos concatenar texto u otras variables, para de este modo poder especificar a través de variable la consulta que queremos ejecutar sobre OPENROWSET u OPENQUERY, y también poder especificar a través de variable lo datos de conexión, como es el caso del Driver OLEDB y la Cadena de Conexión en el caso de OPENROWSET, o el nombre del Servidor Vinculado en el caso de OPENQUERY.
Es importante recordar, que uno de los más importantes problemas de la utilización de SQL Dinámico, es el riesgo de sufrir ataques SQL Injection, lo cual queda fuera del alcance del presente artículo (lo que no quita, que debamos tenerlo en cuenta, claro... ).
A continuación se muestra un ejemplo de SQL Dinámico y OPENROWSET:
DECLARE @DriverOLEDB AS NVARCHAR(50)
DECLARE @ConnString AS NVARCHAR(100)
DECLARE @Consulta AS NVARCHAR(4000)

SET @DriverOLEDB = N'SQLNCLI'
SET @ConnString = N'Server=NombreServidor\NombreInstancia;Trusted_Connection=yes;'
SET @Consulta = N'SELECT * FROM NombreBaseDatos.dbo.NombreTabla'

DECLARE @SQL NVARCHAR(4000)
SET @SQL=N'SELECT * FROM OPENROWSET(''' + @DriverOLEDB + ''', ''' + @ConnString + ''', N''' + @Consulta + ''')'

EXEC sp_executesql @SQL
Téngase en cuenta, que es posible ejecutar SQL Dinámico tanto con sp_executesql como con EXECUTE. Soy partidario y tengo costumbre de utilizar sp_executesql, aunque la diferencia entre ambos métodos queda fuera del alcance de este artículo.
Resulta interesante recordar la posiblidad de ejecutar consultas MDX desde SQL Server, especificando los datos de conexión de la instancia de Analysis Services deseada (empleando el Proveedor MSOLAP). Igualmente, resulta interesante para poder ejecutar consultas SQL sobre otros motores de base de datos relacionales, como es el caso de Informix, DB2, ORACLE, etc.

Comentarios

Entradas populares de este blog

¿En qué puerto TCP escucha SQL Server 2005? ¿Cómo cambiar o configurar el puerto TCP de escucha de una Instancia de SQL Server 2005?

Una buena práctica inmediatamente después de instalar SQL Server 2005 es cambiar el Puerto TCP de escucha, por múltiples motivos: Seguridad, Configuración de reglas de acceso de Firewall, Aplicaciones cliente que requieren un puerto TCP estático para SQL Server, etc. En este Artículo se explica cómo averiguar en qué puerto TCP escucha SQL Server 2005, cómo cambiar el puerto TCP de escucha de SQL Server 2005, etc. Resulta de gran interés ser capaz de responder a la pregunta  ¿En qué puerto TCP escucha SQL Server?  Por defecto, una  Instancia por Defecto de SQL Server 2005  queda configurada durante la instalación para escuchar en el  puerto TCP-1433 , sin embargo,  las Instancias con Nombre  quedan configuradas durante el proceso de instalación para escuchar en  puertos TCP dinámicos , por lo tanto, cada vez que se inicie la Instancia puede que escuche en un puerto diferente. Esta situación puede resultar problemática, por un lado desde el punto de vista de la seguridad (el hecho d

¿Qué es el nivel de aislamiento (Isolation Level) de una Transacción? ¿Qué niveles de aislamiento ofrece SQL Server?

Esta capítulo explica qué es el nivel de aislamiento (isolation level) de una transacción, el comportamiento de SQL Server en operaciones de lectura o de escritura, se detallan los diferentes niveles de aislamiento basados en bloqueos (READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE) y los niveles de aislamiento basados en versionado de filas (READ COMMITTED SNAPSHOT, SNAPSHOT), se explican los males de la concurrencia (lecturas sucias, lecturas no repetibles, lecturas fantasma, y conflictos de actualización), como establecer el nivel de aislamiento deseado (SET TRANSACTION ISOLATION LEVEL y las opciones de base de datos READ_COMMITTED_SNAPSHOT y ALLOW_SNAPSHOT_ISOLATION), cómo conecer el tiempo máximo de bloqueo (@@LOCK_TIMEOUT) y como establecer el tiempo máximo de bloqueo (SET LOCK_TIMEOUT), etc. El nivel de aislamiento de una transacción (transaction isolation level)  define el grado en que se aísla una transacción de las modificaciones de recursos o datos rea

Aumentar y Reducir la TempDB en SQL Server?

Una buena práctica después de instalar SQL Server (y que interesa revisar periódicamente) es tener bien dimensionada la base de datos TEMPDB, es decir que el  tamaño inicial de TEMPDB  sea suficiente, y en consecuencia no sea necesario que TEMPDB crezca ni tampoco reducir TEMPDB (SHRINK). Esta artículo explica brevemente  para qué sirve TEMPDB , explica camo cambiar el tamaño inicial de TEMPDB (aumentar o reducir),  cómo reducir TEMPDB , cuántos ficheros son recomendables para TEMPDB, etc. ¿Para qué sirve TEMPDB?  La base de datos TEMPDB es un elemento de gran importancia en una Instancia de SQL Server, ya que  TEMPDB es la encargada de almacenar tanto los objetos temporales  (tablas temporales, procedimientos almacenados temporales, etc.),  como los resultados intermedios  que pueda necesitar crear el motor de base de datos, por ejemplo durante la ejecución de consultas que utilizan las cláusulas GROUP BY, ORDER BY, DISTINCT, etc. (es decir, las tablas temporales o WorkTables que