No SQL Server, há uma configuração de “acesso a dados” que habilita e desabilita um servidor vinculado para acesso distribuído a consultas. Se você receber o erro “O servidor não está configurado para ACESSO A DADOS”, provavelmente é porque você está tentando executar uma consulta distribuída em um servidor vinculado que não está configurado para acesso a dados. Isso também pode acontecer quando você tenta executar
OPENQUERY() contra o seu servidor local. Você pode usar
sp_serveroption para habilitar ou desabilitar o acesso a dados em um determinado servidor. No entanto, convém verificar as configurações existentes antes de começar a alterá-las. Os exemplos a seguir mostram como fazer isso. Exemplo 1 – Consultar os sys.servers Visualização do sistema
Provavelmente, a melhor maneira de verificar se o acesso a dados está ativado é consultar o
sys.servers visualização do catálogo do sistema. Você pode retornar todas as colunas ou apenas aquelas que deseja retornar. Aqui está um exemplo de retorno de duas colunas:SELECT name, is_data_access_enabled FROM sys.servers;
Resultado:
+--------------+--------------------------+ | name | is_data_access_enabled | |--------------+--------------------------| | sqlserver007 | 0 | | Homer | 1 | +--------------+--------------------------+
Nesse caso, o acesso aos dados é habilitado para o servidor chamado Homer , mas não para o servidor chamado sqlserver007 .
Exemplo 2 – Execute o sp_helpserver Procedimento armazenado do sistema
O
sp_helpserver procedimento armazenado do sistema também nos fornecerá essas informações, embora em um 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 | +--------------+--------------------------------+----------------------------------+------+------------------+-------------------+-----------------+
Se você olhar no status coluna, você verá que acesso a dados está incluído na linha de Homer , mas não para sqlserver007 .
Em qual servidor eu executo o código?
Você precisa executar o código no local servidor, não o servidor remoto. Com isso quero dizer, se você estiver verificando se pode executar consultas distribuídas em um servidor vinculado, execute o código no servidor do qual você pretende executar consultas distribuídas de .
No meu exemplo, sqlserver007 é o nome do servidor local e Homer é um servidor remoto/vinculado. Se eu quisesse executar consultas distribuídas em Homer , eu executaria o código em sqlserver007 para ver se o acesso a dados está ativado para o Homer servidor vinculado.
Não preciso pular para Homer para verificar sua configuração. Na verdade, se eu pular, ele pode ter uma configuração diferente.
Para demonstrar esse ponto, eis o que recebo se comparar os resultados do servidor vinculado com a configuração real no 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 | +--------------------+--------------------------+
Nesse caso, o servidor local tem uma configuração diferente da contraparte do servidor vinculado.
O fato de eu ter conseguido recuperar essas informações por meio de uma consulta distribuída suporta a afirmação de que foi a configuração do meu próprio servidor que permitiu a consulta distribuída.
