O erro “O servidor não está configurado para ACESSO A DADOS” no SQL Server é um erro comum ao tentar executar uma consulta distribuída em um servidor que tem sua configuração de acesso a dados desabilitada.
O erro terá o nome do servidor que você está tentando acessar. Por exemplo, se o nome do seu servidor for SQL01, o erro será algo assim:
Msg 7411, Level 16, State 1, Line 1 Server 'SQL01' is not configured for DATA ACCESS.
“Acesso a dados” é uma configuração que habilita e desabilita um servidor vinculado para acesso distribuído a consultas.
Uma causa comum desse erro é quando você tenta executar
OPENQUERY() contra o servidor local. Se você realmente deseja executar OPENQUERY() contra o servidor, você precisará garantir que o acesso a dados esteja habilitado para esse servidor – mesmo que seja seu servidor local. Este artigo apresenta um exemplo de execução de uma consulta que gera o erro, verificando se um servidor tem acesso a dados habilitado, habilitando o acesso a dados, verificando novamente e, finalmente, executando a consulta novamente. Se você não quiser percorrer todo o cenário, role para baixo até o título “A solução” abaixo. Como alternativa, confira Como habilitar e desabilitar o acesso a dados no SQL Server para obter um exemplo rápido de habilitar e desabilitar o acesso a dados.
Confira também 2 maneiras de verificar se o acesso a dados está ativado se você quiser apenas verificar a configuração.
Caso contrário, continue lendo – está tudo coberto neste artigo.
Exemplo 1 – O erro
Aqui está um exemplo de um cenário que causa o erro.
SELECT COLUMN_NAME, TYPE_NAME, PRECISION, LENGTH FROM OPENQUERY ( sqlserver007, 'EXEC WideWorldImporters.[dbo].[sp_columns] Cities, Application;' );
Resultado:
Msg 7411, Level 16, State 1, Line 1 Server 'sqlserver007' is not configured for DATA ACCESS.
Neste caso, estou tentando executar
OPENQUERY() contra meu próprio servidor local chamado
sqlserver007
, mas falha, porque o servidor não tem acesso a dados habilitado. Você pode estar se perguntando por que estou executando
OPENQUERY() contra meu próprio servidor quando eu poderia simplesmente chamar o procedimento armazenado localmente? Isso é verdade, mas neste caso o procedimento armazenado retorna mais colunas do que eu preciso, então achei que seria fácil apenas executá-lo através de OPENQUERY() para que eu pudesse escolher as colunas que preciso. Ah! Não é tão fácil quanto eu pensava! Mas esse pequeno soluço é fácil de resolver, então vamos continuar.
Exemplo 2 – Verifique a configuração de acesso a dados
Podemos ver se um servidor tem acesso a dados habilitado verificando o
sys.servers visualização do catálogo do sistema. 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 .
Caso esteja interessado, o
sp_helpserver procedimento armazenado do sistema também nos dará esta informação: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 .
Exemplo 3 – A Solução
Veja como permitir o acesso a dados.
EXEC sp_serveroption @server = 'sqlserver007', @optname = 'DATA ACCESS', @optvalue = 'TRUE';
Resultado:
Commands completed successfully.
Exemplo 4 – Verifique novamente a configuração
Agora podemos verificar novamente a configuração de acesso a dados.
SELECT name, is_data_access_enabled FROM sys.servers;
Resultado:
+--------------+--------------------------+ | name | is_data_access_enabled | |--------------+--------------------------| | sqlserver007 | 1 | | Homer | 1 | +--------------+--------------------------+
Agora meu servidor local tem acesso a dados habilitado.
E aqui está o que parece com
sp_helpserver :EXEC sp_helpserver;
Resultado:
+--------------+--------------------------------+----------------------------------------------+------+------------------+-------------------+-----------------+ | name | network_name | status | id | collation_name | connect_timeout | query_timeout | |--------------+--------------------------------+----------------------------------------------+------+------------------+-------------------+-----------------| | sqlserver007 | sqlserver007 | rpc,rpc out,data access,use remote collation | 0 | NULL | 0 | 0 | | Homer | NULL | data access,use remote collation | 1 | NULL | 0 | 0 | +--------------+--------------------------------+----------------------------------------------+------+------------------+-------------------+-----------------+
Agora podemos ver que acesso a dados foi adicionado sob o status coluna.
Exemplo 5 – Execute novamente a consulta original
Agora que habilitamos o acesso aos dados, vamos executar novamente a consulta original.
SELECT COLUMN_NAME, TYPE_NAME, PRECISION, LENGTH FROM OPENQUERY ( sqlserver007, 'EXEC WideWorldImporters.[dbo].[sp_columns] Cities, Application;' );
Resultado:
+--------------------------+-------------+-------------+------------+ | COLUMN_NAME | TYPE_NAME | PRECISION | LENGTH | |--------------------------+-------------+-------------+------------| | CityID | int | 10 | 4 | | CityName | nvarchar | 50 | 100 | | StateProvinceID | int | 10 | 4 | | Location | geography | 2147483647 | 2147483647 | | LatestRecordedPopulation | bigint | 19 | 8 | | LastEditedBy | int | 10 | 4 | | ValidFrom | datetime2 | 27 | 54 | | ValidTo | datetime2 | 27 | 54 | +--------------------------+-------------+-------------+------------+
Desta vez ele roda sem erro.
Embora este exemplo tenha usado um
OPENQUERY() ao meu servidor local, a mesma correção se aplicaria se eu estivesse tentando executar uma consulta distribuída em um servidor vinculado (remoto). Independentemente disso, as etapas acima ainda são feitas no meu servidor local (não é necessário tocar no servidor remoto). 
