Массовая загрузка невозможна так как файл не удалось открыть

Обновлено: 06.07.2024

Я пытаюсь настроить хранимую процедуру как задание агента SQL Server и выдает следующую ошибку:

Невозможно выполнить массовую загрузку, поскольку файл "P: \ file.csv" не может быть открыт. Код ошибки операционной системы 3 (не удалось получить текст для этой ошибки. Причина: 15105). [SQLSTATE 42000] (ошибка 4861)

Забавно, что хранимая процедура работает просто отлично, когда я выполняю ее вручную.

Диск P: это общий диск на Windows SQL Server из LINUX через Samba Share, и он был настроен с помощью следующей команды:

EXEC xp_cmdshell 'net use P: "\ lnxusanfsd01 \ Data" Пароль /пользователь: имя пользователя /Постоянный: Да'

Любая помощь по этому вопросу будет принята с благодарностью

Я не знаю, решили ли вы эту проблему, но у меня возникла та же проблема: если экземпляр локальный, вы должны проверить разрешение на доступ к файлу, но если вы обращаетесь с вашего компьютера к серверу (удаленный доступ), у вас есть указать путь на сервере, что означает включение файла в каталог сервера, что решило мой случай

Для простоты я просто изменил каталог, из которого я импортировал данные, в локальную папку на сервере .

У меня был файл, расположенный в общей папке, я просто скопировал свои файлы в «c: \ TEMP \ Reports» на моем сервере (обновил запрос до BULK INSERT из новой папки). Задача агента успешно выполнена:)

Наконец, через долгое время я могу автоматически добавлять BULK через задание агента.

Я бы предположил, что диск P: не сопоставлен с учетной записью, с которой запущен сервер sql.

Вероятно, это проблема с разрешениями, но вам нужно обязательно выполнить следующие шаги для устранения неполадок:

  • Поместите файл на локальный диск и посмотрите, работает ли задание (вам не обязательно нужен доступ RDP, если вы можете сопоставить букву диска на вашей локальной рабочей станции с каталогом на сервере базы данных)
  • Поместите файл в удаленный каталог, который не требует имени пользователя и пароля (позволяет всем читать), и используйте путь UNC (\ server \ directory \ file.csv)
  • Настройте задание SQL для запуска под своим именем пользователя
  • Сконфигурируйте задание SQL для запуска как sa и добавьте net use и net use /delete до и после

Не забудьте отменить любые изменения (особенно при выполнении в виде sa ). Если больше ничего не работает, вы можете попытаться изменить массовую загрузку на запланированное задание, работающее на сервере базы данных или другом сервере, на котором установлен bcp.

Я попытался дать доступ к папкам, но это не помогло. Мое решение состояло в том, чтобы сделать выделенные ниже параметры в красном выбранными для вошедшего в систему пользователя

 Это то, что вы видите, когда щелкаете правой кнопкой мыши и выбираете имя пользователя, в которое вы вошли для режима аутентификации Windows.

Использование соединения SQL через аутентификацию Windows: Происходит «двойной переход Kerberos»: один прыжок - это ваше клиентское приложение, подключающееся к SQL Server, второй переход - это SQL Server, подключающийся к удаленному «\\ NETWORK_MACHINE \». Такой двойной прыжок подпадает под ограничения Ограниченного делегирования, и вы в конечном итоге получаете доступ к общему ресурсу как анонимный вход и, следовательно, доступ запрещен.

Чтобы решить эту проблему, необходимо включить ограниченное делегирование для учетной записи службы SQL Server. Смотрите здесь хороший пост, который объясняет это довольно хорошо

SQL Server с использованием аутентификации SQL Вам необходимо создать учетные данные для входа в SQL и использовать их для доступа к этому конкретному сетевому ресурсу. см. здесь

по какой-то странной причине у меня возникли проблемы с выполнением массовой вставки.

Я уверен после чтения этой что я правильно настроил свою роль пользователя, как говорится.

члены фиксированной роли сервера bulkadmin могут запускать инструкцию BULK INSERT.

я поставил Login Properties для проверки подлинности windows правильно (как показано ниже).. предоставление разрешений на уровне сервера bulkadmin

и команды EXEC sp_helpsrvrolemember 'bulkadmin' говорит мне, что информация выше была успешной, и текущий пользователь Michael-PCMichael и bulkadmin разрешения.

но даже если я все правильно настроил, насколько я знаю, я все еще получаю ошибку. выполнение массовой вставки непосредственно из SQL Студия Управления Сервером.

Msg 4861, Уровень 16, Состояние 1, Строка 2
Массовая загрузка невозможна, так как файл "C:UsersMichaelworkspacepydbdataandrew.из.txt " не удалось открыть. Код ошибки операционной системы 5(отказано в доступе.).

эта ошибка появляется при использовании проверки подлинности SQL Server и SQL Server не разрешен доступ к папке массовой загрузки.

enter image description here

таким образом, предоставление SQL server доступа к папке решит проблему.

вот как: Перейдите в папку щелкните правой кнопкой мыши - >свойства - > вкладка Безопасность - >изменить - >добавить (в новом окне) ->дополнительно -> найти сейчас. В списке пользователей в результатах поиска найдите что - то вроде SQLServerMSSQLUser$UserName$SQLExpress и нажмите ok, чтобы все диалоги открылись.

Я не думаю, что переустановка SQL Server исправит это, это просто убьет некоторое время.

  1. убедитесь, что ваша учетная запись пользователя имеет права на чтение в указанную папку.
  2. используйте такой инструмент, как Контролировать Процесс чтобы увидеть, что пользователь на самом деле пытается получить доступ к файлу.

Я предполагаю, что это не Michael-PC\Michael Это попытка получить доступ к файлу, а скорее к учетной записи службы SQL Server. Если это так, то у вас есть как минимум три варианта (но, возможно, и другие):

a. Установите службу SQL Server для запуска от вашего имени.
b. Предоставьте учетной записи службы SQL Server явный доступ к этой папке.
c. Поместите файлы в более логичное место, где SQL Server имеет доступ или может иметь доступ (например, C:\bulk\ ).

Я предлагаю эти вещи, предполагая, что это замкнутая локальная рабочая станция. Есть определенно более серьезные проблемы безопасности вокруг доступ к локальной файловой системе с SQL Server когда мы говорим о производственной машине, конечно, это все еще можно в значительной степени смягчить с помощью c. выше-и только предоставление учетной записи службы доступа к папкам, которые вы хотите, чтобы она могла коснуться.

попробуйте дать папку(ы), содержащую CSV и разрешение на чтение файла формата для пользователя "MSSQLSERVER" (или любого пользователя, для которого служба SQL Server установлена в Войдите В Систему на Службы Windows)

У меня была та же проблема SSIS 2012, и решение состояло в использовании проверки подлинности Windows. Я использовал проверку подлинности SQL с пользователем sa.

убедитесь, что файл, который вы используете ( 'C:\Users\Michael\workspace\pydb\data\andrew.out.txt' ) находится на компьютере SQL server, а не на клиентском компьютере с MSSMS.

1) Открыть SQL 2) в Диспетчере задач вы можете проверить, на какой учетной записи запущен SQL - это, вероятно, не Michael-PC\Michael, как писал Ян.

учетная запись, которая запускает SQL, нуждается в доступе к общей папке.

Я пытаюсь настроить хранимую процедуру как задание агента SQL Server, и она дает мне следующую ошибку:

Массовая загрузка невозможна, так как не удалось открыть файл «P:\file.csv». Код ошибки операционной системы 3 (не удалось получить текст для этой ошибки. Причина: 15105). [SQLSTATE 42000] (ошибка 4861)

Забавно, что хранимая процедура прекрасно работает, когда я выполняю ее вручную.

Диск P: является общим диском в Windows SQL Server из LINUX через Samba Share, и он был настроен с помощью следующей команды:

EXEC xp_cmdshell 'Net Use P: "\ lnxusanfsd01\Data" Пароль/пользователь: имя пользователя/Постоянный: Да'

Любая помощь по этому вопросу будет принята с благодарностью

Я не знаю, если вы решили эту проблему, но у меня была та же проблема, если экземпляр является локальным, вы должны проверить разрешение на доступ к файлу, но если вы обращаетесь с вашего компьютера к серверу (удаленный доступ), вы должны указать путь к серверу, что означает включение файла в каталог сервера, что решило мой случай

Для простоты, я просто изменил каталог, из которого я импортировал данные в локальную папку на сервере .

У меня был файл, расположенный в общей папке, я просто скопировал свои файлы в «c:\TEMP\Reports» на моем сервере (обновил запрос до BULK INSERT из новой папки). Задача агента успешно выполнена :)

Наконец, через долгое время я могу BULK вставлять автоматически через работу агента.

С наилучшими пожеланиями.

Я решил эту проблему,

войдите на сервер, на котором установлен SQL Server, и получите csv файл на сервере и выполнить ваш запрос, он вставит записей.

Если вы сообщите о проблеме совместимости типов данных, измените тип данных для этого столбца.

Я бы предположил, что диск P: не сопоставлен с учетной записью, на которой запущен сервер sql.

Я попытался предоставить доступ к папкам, но это не помогло Мое решение состояло в том, чтобы сделать выделенные ниже параметры, выделенные красным, для выбранного пользователя.

This is what you see when you right click and select the username you have logged in for windows authentication mode.

Вероятно, это проблема с разрешениями, но вам нужно обязательно попробовать эти шаги для устранения неполадок:

  • Поместите файл на локальный диск и посмотрите, работает ли задание (вам не обязательно нужен доступ RDP, если вы можете сопоставить букву диска на вашей локальной рабочей станции с каталогом на сервере базы данных)
  • Поместите файл в удаленный каталог, который не требует имени пользователя и пароля (позволяет всем читать) и используйте путь UNC (\ server\directory\file.csv)
  • Настройте задание SQL для запуска под своим именем пользователя
  • Сконфигурируйте задание SQL для запуска от имени sa и добавьте команды Net Use и Net Use /delete до и после

Не забудьте отменить любые изменения (особенно при работе с sa ). Если больше ничего не работает, вы можете попробовать превратить массовую загрузку в запланированное задание, работающее на сервере базы данных или другом сервере, на котором установлен bcp.

Использование соединения SQL через проверку подлинности Windows: «Двойной прыжок Kerberos»: один прыжок - это ваше клиентское приложение, подключающееся к SQL Server, второй прыжок - SQL Server, подключающийся к удаленному «\\ NETWORK_MACHINE \». Такой двойной прыжок подпадает под ограничения Ограниченного делегирования, и вы в конечном итоге получаете доступ к общему ресурсу как анонимный вход и, следовательно, доступ запрещен.

Чтобы решить эту проблему, необходимо включить ограниченное делегирование для учетной записи службы SQL Server. Смотрите здесь хороший пост, который объясняет это довольно хорошо

SQL Server с использованием аутентификации SQL Вам необходимо создать учетные данные для входа в SQL и использовать их для доступа к этому конкретному сетевому ресурсу. Посмотреть здесь

По какой-то странной причине у меня проблемы с выполнением массовой вставки.

После прочтения я уверен, что правильно настроил свою роль пользователя, как говорится .

Члены фиксированной серверной роли bulkadmin могут выполнять инструкцию BULK INSERT.

Я установил Login Properties для проверки подлинности Windows правильно (как показано ниже) .. для предоставления разрешений на уровне сервера на bulkadmin


И команда EXEC sp_helpsrvrolemember 'bulkadmin' сообщает мне, что информация выше была успешной, и текущий пользователь Michael-PC\Michael имеет bulkadmin разрешения.


Но даже несмотря на то, что я все настроил правильно, насколько мне известно, я все равно получаю ошибку. выполнение массовой вставки непосредственно из SQL Server Management Studio.

Я решил эту проблему довольно просто:

ваша проблема решена.

Эта ошибка появляется, когда вы используете проверку подлинности SQL Server и SQL Server не имеет доступа к папке массовой загрузки.

Таким образом, предоставление SQL-серверу доступа к папке решит проблему.


Вот как: Перейдите в папку правой кнопкой мыши -> свойства-> вкладка Безопасность-> Правка-> Добавить (в новом окне) -> Дополнительно -> Найти сейчас. Под списком пользователей в результатах поиска найдите что-то вроде SQLServerMSSQLUser $ UserName $ SQLExpress и нажмите ОК, чтобы открылись все диалоговые окна.

Я не думаю, что переустановка SQL Server исправит это, это просто убьет некоторое время.

  1. Подтвердите, что ваша учетная запись пользователя имеет права на чтение указанной папки.
  2. Используйте такой инструмент, как Process Monitor, чтобы узнать, какой пользователь на самом деле пытается получить доступ к файлу.

Я предполагаю, что это не так Michael-PC\Michael который пытается получить доступ к файлу, а скорее к учетной записи службы SQL Server. В этом случае у вас есть как минимум три варианта (но, вероятно, другие):

а. Настройте службу SQL Server на работу от вашего имени.
б. Предоставьте учетной записи службы SQL Server явный доступ к этой папке.
c. Поместите файлы в более логичное место, где у SQL Server есть доступ или где можно сделать доступ (например, C:\bulk\ ).

Я предлагаю эти вещи, предполагая, что это локальная рабочая станция. Определенно, существуют более серьезные проблемы безопасности, связанные с доступом к локальной файловой системе из SQL Server, когда мы говорим о производственной машине, конечно, это все еще можно в значительной степени уменьшить, используя c. выше - и предоставляя учетной записи службы доступ только к тем папкам, к которым вы хотите, чтобы она могла касаться.

  • Это просто машина, которую я использую для создания и тестирования программного обеспечения, а не производственную систему.

У меня была такая же проблема с SSIS 2012, и решением было использовать проверку подлинности Windows. Я использовал аутентификацию SQL с пользователем sa.

Попробуйте предоставить папки, содержащие права на чтение CSV и Format File, для пользователя MSSQLSERVER (или любого другого пользователя, для которого служба SQL Server настроена на Войти как в Службы Windows)

  • Большое спасибо - после ответа @antew я пытался найти SQL или MSSQL в списке, но не могу. Понимаю MSSQL является log on as "местная служба" в windows service . Я добавил "локальную службу" к безопасности и исправил проблему с разрешением.
  1. Перейти к запуску run => services.msc => SQL SERVER (MSSQLSERVER) остановить службу
  2. Щелкните правой кнопкой мыши SQL SERVER (MSSQLSERVER) => properties => LogOn Tab => Local System Account => OK
  3. Перезапустите SQL Server Management Studio.
  • Из всех многочисленных предлагаемых решений, которые я нашел в Интернете, это действительно решило мою проблему. Спасибо, @Vinay Patel

Убедитесь, что файл, который вы используете ( 'C:\Users\Michael\workspace\pydb\data\andrew.out.txt' ) находится на компьютере с SQL-сервером, а не на клиентском компьютере, на котором выполняется MSSMS.

  • Клиентская машина - это sql-сервер (машина разработки)

1) Откройте SQL 2) В диспетчере задач вы можете проверить, какая учетная запись запускает SQL - вероятно, это не Michael-PC \ Michael, как написал Ян.

Учетной записи, которая запускает SQL, требуется доступ к общей папке.

Если задействована DFS, вы можете выполнить следующую команду Powershell, чтобы получить имя файлового сервера:

Вот что сработало для меня:

Войдите в SSIS с проверкой подлинности Windows.

1. Откройте службы, найдите имя учетной записи службы MSSQL NT и скопируйте его:


2. Откройте папку, из которой должен читать SQL-сервер. Безопасность - вкладка Группы или имена пользователей - Добавить и вставьте туда скопированный аккаунт: **



Ваш BULK INSERT теперь запрос должен работать нормально. Если проблема не исчезнет, ​​попробуйте таким же образом добавить учетную запись агента SQL Server в разрешения папки. Обязательно перезапустите сервер MSSQL в службах после того, как закончите.

Читайте также: