Обнаружен непредвиденный символ eof в файле данных bcp
Обновлено: 07.07.2024
В этом разделе мы рассмотрим несколько примеров использования BCP для загрузки данных в SQL Server и из SQL Server. Эти примеры не охватывают все возможности, но они дадут вам хорошее представление о разнообразных режимах и методах работы с помощью BCP .
Вы можете использовать BCP из командной строки, как это описано выше, или в интерактивном стиле. Для вызова BCP без какого-либо дополнительного взаимодействия с этой программой, вы должны задать параметр -n, -c, -w или -N . Если не указан ни один из этих параметров, то программа BCP будет работать в интерактивном режиме.
Примечание.Во всех следующих примерах используется таблица Customers из базы данных Northwind.Загрузка данных путем интерактивного использования BCP
Использование BCP для загрузки данных в интерактивном режиме может вызывать определенные трудности, поскольку этот метод требует, чтобы вы указывали ширину и типы колонок. Вы не обязаны это делать, если используете параметры командной строки , как это описано в следующем разделе. Хотя использование BCP в интерактивном режиме не рекомендуется, мы рассмотрим пример использования этого метода, чтобы вы имели полное представление о том, как работает BCP . В этом примере мы выполним копирование данных из файла data2.file в таблицу Customers базы данных Northwind с записью ошибок в файл err.file. Вы должны иметь заранее созданный файл данных data2.file. Этот файл содержит данные, которые вам нужно загрузить в таблицу Customers. Для запуска интерактивного сеанса в качестве системного администратора введите следующий оператор:
Затем у вас будет запрошен пароль. Введите пароль системного администратора (sa).
Далее программа BCP будет запрашивать у вас информацию, касающуюся данных, которые вы хотите копировать. Ниже приводится пример интерактивного сеанса. Отметим, что ввод пользователя показан полужирным шрифтом.
Загрузка данных программой BCP с помощью параметров командной строки
Как уже говорилось, вам будет намного проще использовать BCP для загрузки данных, если вы будет использовать параметры командной строки . В примере этого раздела мы будем использовать BCP для загрузки данных из файла данных, состоящего из символьных колонок, разделенных символами табуляции (tab). Чтобы указать, что в файле данных используется символьный формат, мы будем использовать параметр -c . Кроме того, использование параметра -c позволяет выполнять BCP в неинтерактивном режиме. Следующая команда копирует 25 строк данных из файла данных data.file. в таблицу Customers базы данных Northwind:
Поскольку параметр -c указывает символьные данные, вам не нужно задавать длину полей и длину префиксов. Если предположить, что вы создали файл data.file с 25 строками данных, разделенных символом tab в соответствии с колонками таблицы Customers, и ввели пароль sa, то соответствующий сеанс будет иметь следующую форму: (Размер вашего сетевого пакета и время работы, возможно, будут отличаться.)
В этом примере направление копирования было указано параметром in , т.е. данные копировались в базу данных. Всегда имеет смысл указывать файл ошибок , в котором ведется журнал ошибок , возникших во время сеанса BCP . Если вы не указываете файл ошибок , эти ошибки выводятся на экран и, в конце концов, в результате прокрутки исчезают с экрана.
попытка импорта данных в Azure. Создал текстовый файл в среде Management Studio 2005. Я пробовал текстовый файл с разделителями-запятыми и вкладками.
вот скрипт, который я использовал для создания файла:
Вот таблица, в которую он вставлен в
есть на самом деле несколько сотен тысяч фактических records и я сделали это с другого сервера, единственное различие заключается в версии management studio.
Если файл разделен табуляцией, то флаг командной строки для разделителя столбцов должен быть -t\t -t,
"неожиданный EOF" обычно означает, что столбец или строка Терминатор не то, что вы ожидаете То есть ваши аргументы командной строки для них совпадают с файлом
- Unix против Windows окончания строки
- текстовые данные, содержащие разделитель столбцов (запятая в фактических данных)
- или смесь двух.
SSMS не должны иметь ничего общего с этим: это формат (ожидаемый vs фактический), который имеет значение
просто FYI, что я столкнулся с этой же точной ошибкой, и оказалось, что моя таблица назначения содержит один дополнительный столбец, чем файл DAT!
Я думаю, что большинство из нас предпочитают реальные примеры, чем синтаксические подсказки, поэтому вот что я сделал:
ППГ LoadDB.dbo.тест в C:\temp\test - . txt-S 123.66.108.207 - U testuser-P testpass-c-r /r
мои данные были извлечением из БД Oracle на базе Unix, которая была разделена табуляцией и имела символ конца строки LF.
поскольку мои данные были разделены табуляцией, я не указал параметр a-t, значение по умолчанию BCP-tab.
потому что моя строка Терминатор был символом LineFeed (LF), затем я использовал-r /r
поскольку все мои данные загружались в поля char, я использовал параметр-c
I в каждом случае, когда я столкнулся с этой ошибкой, это заканчивается проблемой, когда количество столбцов в таблице не соответствует количеству столбцов, разделенных в текстовом файле. Простой способ подтвердить это-загрузить текстовый файл в excel и сравнить количество столбцов с количеством столбцов в таблице.
Я поделюсь своим опытом в этом вопросе. Мои пользователи отправляли мне кодировку UTF-8, и все работало нормально. Моя загрузка начала терпеть неудачу, когда они обновили кодировку для кодирования в UCS-2 LE BOM. Используйте notepad++ для проверки этих параметров.
Попытка импортировать данные в Azure. Создал текстовый файл в Management Studio 2005. Я пробовал текстовый файл с запятой и табуляцией.
Вот скрипт, который я использовал для создания файла:
Вот таблица, в которую она вставлена
На самом деле существует несколько сотен тысяч реальных записей, и я сделал это с другого сервера, единственное отличие заключается в версии студии управления.
Если файл разделен табуляцией, то флаг командной строки для разделителя столбцов должен быть -t\t -t,
Просто к вашему сведению, что я столкнулся с той же самой ошибкой, и оказалось, что моя таблица назначения содержит один дополнительный столбец, чем файл DAT!
"Неожиданный EOF" обычно означает, что терминатор столбца или строки не соответствует ожидаемому. То есть аргументы командной строки для них совпадают с файлом
- Концы строк Unix и Windows
- Текстовые данные, содержащие разделитель столбцов (запятая в реальных данных)
- Или смесь двух.
SSMS не должна иметь к этому никакого отношения: важен формат (ожидаемый или фактический)
В каждом случае, когда я сталкивался с этой ошибкой, она заканчивается тем, что количество столбцов в таблице не совпадает с количеством столбцов, разделенных в текстовом файле. Простой способ убедиться в этом - загрузить текстовый файл в Excel и сравнить количество столбцов с таблицей.
Я думаю, что большинство из нас предпочитают реальные примеры, а не синтаксические подсказки, поэтому вот что я сделал:
bcp LoadDB.dbo.test в C:\temp\test.txt -S 123.66.108.207 -U testuser -P testpass -c -r /r
Мои данные были извлечены из базы данных Oracle на базе Unix, которая была разделена табуляцией и имела символ конца строки LF.
Поскольку мои данные были разделены символом табуляции, я не указал параметр -t, поэтому bcp по умолчанию - tab.
Поскольку мой терминатор строки был символом LineFeed (LF), я использовал -r / r
Поскольку все мои данные загружались в поля типа char, я использовал параметр -c
У меня есть некоторая конфиденциальная информация, которую мне нужно импортировать в SQL Server, что оказалось проблемой. Я не уверен, что это была за исходная база данных, в которой размещалась эта информация, но я знаю, что она предоставляется нам в виде текстового файла фиксированной длины Unix с ограничителем строки LF. У меня есть два файла: небольшой файл, охватывающий данные за месяц, и файл гораздо большего размера, охватывающий данные за 5 лет. Я создал файл формата BCP и команду, которая успешно импортирует и отображает данные в мою таблицу SQL Server.
Данные за 5 лет предположительно в том же формате, поэтому я использовал ту же команду и файл формата в текстовом файле. Он начинает обрабатывать некоторые записи, но где-то в процессе обработки (после нескольких тысяч записей) он выдает обнаруженный неожиданный EOF, и я вижу в базе данных, что некоторые строки отображаются правильно в соответствии с фиксированной длиной, но затем что-то идет ужасно неправильно и облажается, вставляя части данных в столбцы, которым они определенно не принадлежат. Есть ли символ, который может вызвать сбой и преждевременное завершение работы BCP?
Опять же, файл форматирования и команда отлично работают для меньшего набора данных, но что-то в 5-летнем наборе данных портит BCP.
Заранее благодарим за ответы!
1 ответ
Итак, я нашел оскорбительные символы в моем файле с фиксированной шириной. Каким-то образом тот, кто изначально вытащил данные (у меня нет доступа к источнику), экранировал (или не экранировал правильно) двойные кавычки в некоторой части текста, что привело к некоторой инъекции дополнительных пробелов, нарушающих рекомендации фиксированной ширины, которые мы предполагали следовать. После исправления двойных кавычек шестнадцатеричным редактированием файла BCP смог без проблем обрабатывать все записи с использованием файла формата. Я использовал флаги -F и -L для проверки определенных строк данных и сужения их до того, где я мог визуально сравнить строки, которые были в порядке, и строки, в которых начали возникать проблемы, что привело меня к обнаружению двойного вопрос котировок. Надеюсь, что он поможет кому-то еще, если у них возникнет подобная проблема!
Читайте также: