web-dev-qa-db-fra.com

SSMS - Impossible de charger en masse car le fichier n'a pas pu être ouvert

Nous avons un utilisateur qui reçoit ce message d'erreur chaque fois que le chargement en masse à l'aide de l'emplacement réseau génère une erreur ci-dessous.

"Impossible de charger en bloc car le fichier n'a pas pu être ouvert. Code d'erreur 3 du système d'exploitation (impossible de récupérer le texte de cette erreur. Raison: 15105)."

  • Si les utilisateurs se connectent au serveur distant et exécutent la même requête, cela fonctionne correctement

  • Le nom de domaine complet est spécifié pour l'emplacement du fichier (\ servername\sharename\filename.txt)

  • Lorsque le fichier est copié sur le serveur (lecteur C: \), la requête s'exécute correctement via SSMS

  • Nous utilisons SQL Server 2008 R2

J'ai vérifié toutes les autorisations NTFS pour le dossier partagé. J'ai parcouru de nombreux articles suggérant une solution mais pas de chance.

sql-serversql-server-2008-r2ssmsbulk-insert
5
Jatin Patel

winerror.h répertorie le code d'erreur du système d'exploitation comme ERROR_PATH_NOT_FOUND. Cela indique probablement que \\servername\sharename\filename.txt soit n'existe pas, soit le compte de service SQL Server n'a pas accès au fichier via l'UNC.

Utilisez SQL Server Configuration Manager pour déterminer le nom du compte de service SQL Server:

enter image description here

Vérifiez la sécurité du partage de fichiers pour l'UNC pour vous assurer que le compte a accès au partage. Vérifiez la sécurité du système de fichiers pour le dossier sous-jacent UNC pour vous assurer que le compte a accès au fichier.

T-SQL BULK INSERT nécessite ne compréhension de l'architecture de sécurité . Tiré de cette page:

Si un utilisateur utilise une connexion SQL Server, le profil de sécurité du compte de processus SQL Server est utilisé. Une connexion utilisant l'authentification SQL Server ne peut pas être authentifiée en dehors du moteur de base de données. Par conséquent, lorsqu'une commande BULK INSERT est lancée par une connexion utilisant l'authentification SQL Server, la connexion aux données est établie à l'aide du contexte de sécurité du compte de processus SQL Server (le compte utilisé par le service SQL Server Database Engine). Pour lire correctement les données source, vous devez accorder au compte utilisé par le moteur de base de données SQL Server l'accès aux données source. En revanche, si un utilisateur SQL Server se connecte à l'aide de l'authentification Windows, l'utilisateur peut lire uniquement les fichiers qui peuvent être accessible par le compte d'utilisateur, quel que soit le profil de sécurité du processus SQL Server.

Lorsque vous exécutez l'instruction BULK INSERT à l'aide de sqlcmd ou osql, à partir d'un ordinateur, en insérant des données dans SQL Server sur un deuxième ordinateur et en spécifiant un fichier de données sur un troisième ordinateur à l'aide d'un chemin UNC, vous pouvez recevoir une erreur 4861.

Pour résoudre cette erreur, utilisez l'authentification SQL Server et spécifiez une connexion SQL Server qui utilise le profil de sécurité du compte de processus SQL Server ou configurez Windows pour activer la délégation de compte de sécurité. Pour plus d'informations sur la façon d'activer la confiance d'un compte d'utilisateur pour la délégation, consultez l'aide de Windows.

2
Max Vernon

Étant donné que:

  1. L'erreur se produit lors de l'utilisation d'un fichier sur le réseau

  2. L'erreur ne pas se produit lors de l'utilisation d'un fichier local (local sur le serveur exécutant SQL Server)

  3. L'erreur ne pas se produit lors de l'utilisation d'un fichier sur le réseau SI l'utilisateur se connecte au serveur distant

Je dirais:

  1. Votre utilisateur se connecte avec une connexion Windows

    Si l'utilisateur se connectait avec une connexion SQL Server, le comportement serait le même qu'il se connecte à SQL Server à partir d'un serveur distant ou directement sur le serveur via Remote Desktop. Les connexions SQL Server n'existent pas en dehors de SQL Server (c'est-à-dire dans Windows/Active Directory) et n'ont donc pas de contexte de sécurité pouvant être emprunté. Dans ce cas, le BULK INSERT/OPENROWSET(BULK... processus utilisera le contexte de sécurité existant du compte de service qui exécute le processus SQL Server.

    Lors de la connexion avec une connexion Windows, il existe un contexte de sécurité qui peut être emprunté et donc l'opération en bloc tente de le faire. Le problème ici est que les jetons de sécurité transférés ne peuvent pas, par défaut, être retransmis. C'est pourquoi l'utilisateur obtient l'erreur lors de la connexion à partir de son bureau (il s'est connecté à son bureau pour obtenir le jeton de sécurité, puis s'est connecté à distance à SQL Server, à l'aide d'un jeton de sécurité transféré). Et c'est pourquoi l'utilisateur, lorsqu'il se connecte directement au serveur distant via Remote Desktop, obtient un jeton de sécurité complet de ce serveur et se connecte directement à SQL Server avec lui, et peut donc l'utiliser pour transférer vers un service en réseau, comme un dossier partagé.

  2. Vous devez soit:

    1. ouvrir les autorisations sur le partage pour Everyone ou Domain User ou peu importe

    2. Accédez à Active Directory et configurez cette connexion Windows (pour cet utilisateur) pour la délégation

    3. (peut-être) configurer un utilisateur SQL Server qui peut être emprunté via le EXECUTE AS clause d'un CREATE PROCEDURE et créez une procédure stockée pour effectuer l'opération en bloc. Je n'ai pas essayé cela, donc je ne suis pas tout à fait sûr si cela ferait l'affaire, mais l'idée est de basculer le contexte de sécurité vers celui d'un compte SQL Server de telle sorte que l'opération en bloc ne se fera pas avec l'emprunt d'identité et utilisera simplement le courant contexte de sécurité du compte de service SQL Server. Ça vaut le coup, peut-être.

0
Solomon Rutzky