En SQL Server, hay una configuración de "acceso a datos" que habilita y deshabilita un servidor vinculado para el acceso de consultas distribuidas. Si alguna vez recibe el error "El servidor no está configurado para el ACCESO A LOS DATOS", probablemente se deba a que está intentando ejecutar una consulta distribuida en un servidor vinculado que no está configurado para el acceso a los datos. Esto también puede suceder cuando intenta ejecutar OPENQUERY() contra su servidor local.
Puede usar sp_serveroption para habilitar o deshabilitar el acceso a datos en un servidor determinado. Sin embargo, es posible que desee verificar la configuración existente antes de comenzar a cambiarla. Los siguientes ejemplos muestran cómo hacerlo.
Ejemplo 1:consulta los sys.servers Vista del sistema
Probablemente la mejor manera de verificar si el acceso a datos está habilitado es consultar los sys.servers vista del catálogo del sistema. Puede devolver todas las columnas o solo aquellas que desee que se devuelvan. Aquí hay un ejemplo de devolver dos columnas:
SELECT name, is_data_access_enabled FROM sys.servers;
Resultado:
+--------------+--------------------------+ | name | is_data_access_enabled | |--------------+--------------------------| | sqlserver007 | 0 | | Homer | 1 | +--------------+--------------------------+
En este caso, el acceso a los datos está habilitado para el servidor llamado Homer , pero no para el servidor llamado sqlserver007 .
Ejemplo 2:ejecutar sp_helpserver Procedimiento almacenado del sistema
El sp_helpserver El procedimiento almacenado del sistema también nos dará esta información, aunque en un formato diferente:
EXEC sp_helpserver;
Resultado:
+--------------+--------------------------------+----------------------------------+------+------------------+-------------------+-----------------+ | name | network_name | status | id | collation_name | connect_timeout | query_timeout | |--------------+--------------------------------+----------------------------------+------+------------------+-------------------+-----------------| | sqlserver007 | sqlserver007 | rpc,rpc out,use remote collation | 0 | NULL | 0 | 0 | | Homer | NULL | data access,use remote collation | 1 | NULL | 0 | 0 | +--------------+--------------------------------+----------------------------------+------+------------------+-------------------+-----------------+
Si miras en el estado columna, verá que acceso a datos se incluye en la fila de Homer , pero no para sqlserver007 .
¿En qué servidor ejecuto el código?
Debe ejecutar el código contra el local servidor, no el servidor remoto. Con esto quiero decir, si está comprobando si puede ejecutar consultas distribuidas en un servidor vinculado, ejecute el código en el servidor desde el que pretende ejecutar consultas distribuidas desde .
En mi ejemplo, sqlserver007 es el nombre del servidor local y Homer es un servidor remoto/enlazado. Si quisiera ejecutar consultas distribuidas contra Homer , ejecutaría el código contra sqlserver007 para ver si el acceso a datos está habilitado para Homer servidor vinculado.
No necesito saltar a Homer para comprobar su ajuste. De hecho, si salto, en realidad puede tener una configuración diferente.
Para demostrar este punto, esto es lo que obtengo si comparo los resultados del servidor vinculado con la configuración real en el servidor remoto.
SELECT 'From local', is_data_access_enabled FROM sys.servers WHERE name = 'Homer' UNION ALL SELECT 'Remote setting', is_data_access_enabled FROM Homer.master.sys.servers WHERE server_id = 0;
Resultado:
+--------------------+--------------------------+ | (No column name) | is_data_access_enabled | |--------------------+--------------------------| | From local | 1 | | Remote setting | 0 | +--------------------+--------------------------+
En este caso, el servidor local tiene una configuración diferente a la del servidor vinculado.
El hecho de que pude recuperar esta información a través de una consulta distribuida respalda la afirmación de que fue la configuración de mi propio servidor la que permitió la consulta distribuida.
