Tenho um job configurado no qual transfere o arquivo em local remoto.
Meu comando está sendo executado perfeitamente bem no prompt de comando, mas quando o configurei no trabalho do servidor SQL, ele apresenta falha no login, nome de usuário desconhecido ou senha incorreta.
Não consigo descobrir o motivo exato pelo qual esse arquivo não está sendo transferido.
Se houver um erro no meu código, ele deve fornecer o mesmo erro no prompt de comando. Alguém pode me ajudar a entender por que estou recebendo o erro?
provavelmente porque o usuário que está tentando mover os arquivos é o usuário que está executando o trabalho (provavelmente o usuário que o agente do SQL Server está configurado para executar). Tente dar permissão de leitura a este usuário na pasta da qual você está lendo os arquivos e escreva na pasta em que você está gravando os arquivos.
O problema foi resolvido. Como a pasta de localização remota foi compartilhada e acessível a todos. Meu comando estava funcionando bem no prompt de comando, mesmo qualquer usuário foi capaz de criar seu próprio arquivo naquele local e também deletar o arquivo desse local.
O problema estava relacionado ao usuário. Meu trabalho estava sendo executado por servername\administrator e a senha do administrador do local remoto foi alterada devido a um erro de senha inválida. Contei à minha equipe de TI sobre o problema e eles redefiniram a senha do servidor como antiga, e meu trabalho começou a funcionar bem.
O problema foi resolvido.
Eu só quero saber como meu trabalho sql autentica o login do servidor enquanto passo pelo script do meu trabalho e não encontrei nada útil em relação à autenticação.
Alguém pode me explicar.
Obrigado
Nitesh Kumar
o principal motivo para falhas de arquivos em lote com algo que funciona na linha de comando são os
%sinais.Na linha de comando, um único % é necessário, então
for %a in (*.exe) do echo %afunciona bem, mas se você quiser o mesmo comando em um arquivo em lote, terá que dobrar os sinais %, o que torna esse comando agorafor %%a in (*.exe) do echo %%aIsso é apenas para aqueles que você mesmo calcula - usar variáveis como
%TEMP%não mudaria.Isso é bastante interessante, pois todas as permissões estão sendo sobrepostas repetidamente.
Deixe-me explicar,
Seu Sql Job é executado como um usuário diferente que você conecta ao servidor (alguns casos são iguais, mas esse é o melhor cenário). Você pode verificar isso executando este comando no editor Sql Server (habilitar o xp_cmdshell também):
e compare com o resultado do console (logado como JhonDoe):
Isso geralmente leva o cenário em que ambos os resultados são diferentes, portanto, como você pode imaginar que o script está sendo executado como um usuário diferente, esse usuário pode ter privilégios diferentes.
Então, você precisa entender isso sempre que tentar se conectar a uma pasta compartilhada. Você será solicitado usuário e senha, a menos que seja o mesmo usuário que o proprietário da pasta compartilhada. No entanto, isso pode levá-lo a um mal-entendido.
O que o Windows realmente faz é tentar se conectar à Pasta Compartilhada com as mesmas credenciais com as quais você está conectado:
Você se conectou como JhonDoe com uma senha 123456 no computador chamado PC1, então seu usuário se parece com isso:
A pasta compartilhada pertence a JhonDoe com a senha 123456 (este usuário com essa senha criou a pasta compartilhada) e o computador, chamado PC2, que hospeda a pasta compartilhada mostra isso:
Quando o Windows tenta se conectar à Pasta Compartilhada, ele usa o login PC1 (JhonDoe 123456), pois este é o seu login local e, em seguida, compara com as informações de login remoto e corresponde exatamente ao login PC2 (JhonDoe 123456). Só então, permite que você acesse a pasta compartilhada sem qualquer solicitação de senha.
No entanto, quando se depara com esta situação:
PC1 (JhonDoe-12345)
PC2 (JhonDoe-123456)
As credenciais não correspondem, pois possuem senhas diferentes. Então falha porque são, na verdade, usuários diferentes.