Bcp: Ошибка = [Microsoft] [Собственный клиент SQL Server 10.0] Строковые данные, правильное усечение

Недавно я столкнулся с ошибкой при работе с bcp. Вот ошибка.

SQLState = 22001, NativeError = 0 Ошибка = [Microsoft] [SQL Server Собственный клиент 10.0] Строковые данные, правильное усечение

Я пытаюсь распаковать данные в промежуточную таблицу, которая не имеет никаких ограничений, и типы данных также довольно велики по сравнению с данными. У меня около 11 файлов из разных таблиц, которые bcp'd и zipped, из которых только один файл при распаковке ошибок. Это команда, которую я успешно использую. Совсем недавно (при попытке сделать копию текущего WH и согласования процесса) я столкнулся с проблемами.

bcp.exe employee_details в employee_details.dat -n -E -S "servername" -U sa -P "Пароль"

Я попытался изменить команды на -C -T -S, которые работали, когда я дал формат вручную. Это очень большой и важный пакет, который мне нужно загрузить в мой WH.
Я не знаю, вижу ли здесь файл формата или нет. Любая помощь нужна.

Спасибо

Девушка с корицей.

Ответы

Ответ 1

Мы также столкнулись с такой же проблемой при выполнении BCP, и это оказалось проблемой с новым символом строки в файле .dat.

Просмотрите файл в Notepad ++ и нажмите "Показать все символы", чтобы увидеть новый символ строки.

BCP выдает следующую ошибку с параметром -r "\ r\n", т.е. с помощью команды

bcp dbo.Test in C:\Test.dat -c -t "|" -r "\r\n" -S "DBServerName" -T -E

"SQLState = 22001, NativeError = 0 Ошибка = [Microsoft] [SQL Server Собственный клиент 10.0] Строковые данные, правильное усечение"

BCP обрабатывает все строки в файле как одну строку с параметром -r "\n" или -r "\ r", т.е. с помощью команды

bcp dbo.Test in C:\Test.dat -c -t "|" -r "\n" -S "DBServerName" -T -E

Проблема была решена, когда мы использовали Haxadecimal значение (0x0a) для символа New Line в команде BCP

bcp dbo.Test in C:\Test.dat -c -t "|" -r "0x0a" -S "DBServerName" -T -E

Ответ 2

Для нас оказалось, что файл, который мы пытались загрузить, был в Unicode, а не в формате ANSI.

Существует ключ -N, но в наших таблицах не было данных NVARCHAR.

Мы просто сохранили файл в формате ANSI, и он сработал, но если у вас есть данные NVARCHAR или вам может понадобиться использовать ключ -N

См. TechNet - Использование родного формата Unicode для импорта или экспорта данных

Ответ 3

Ошибка bcp right truncation возникает, когда слишком много данных, которые могут быть установлены в один столбец. Это может быть вызвано неправильными файлами формата (если они используются) или разделителем. Терминатор линии (Windows имеет CRLF или "\ r\n", а UNIX имеет "\n" ) также может вызвать эту ошибку. Пример. Файл формата содержит CRLF Windows, т.е. '\ R\n' в качестве ограничителя строк, но файл содержит "\n" в качестве окончаний строки. Это означало бы подгонку всего файла в 1 строку (скорее 1 столбец), что приведет к ошибке ошибки усечения.

Ответ 4

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

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

У моего входного файла не было данных для третьего столбца в таблице. Так выглядел файл формата.

... ","    1 Cust_Name       SQL_Latin1...
... ","    2 Cust_Ref        SQL_Latin1...
... ","    3 Cust_Amount     SQL_Latin1...
... "\r\n" 4 Cust_notes   SQL_Latin1...

Мой входной файл выглядел так:

Jones,ABC123,200.67,New phone 
Smith,XYZ564,10.23,New SIM

Таблица выглядела как

Cust_Name Varchar(20)
Cust_Ref  Varchar(10)
Cust_Type Varchar(3)
Cust_amount Decimal(10,2)
Cust_Notes Varchar (50)
Cust_Tel   Varchar(15)
Cust......

Я предположил, указав имя столбца в файле формата, что данные перейдут в соответствующий столбец таблицы.

Это, однако, работает, поскольку номер столбца важен, а имя столбца - шум.

... ","    1 A       SQL_Latin1...
... ","    2 B       SQL_Latin1...
... ","    4 C       SQL_Latin1...
... "\r\n" 5 D       SQL_Latin1...

Ответ 5

В моем случае причина была в том, что в одном поле было написано "|" = chr$(124) "|" = chr$(124) и разделитель был в моем случае "|" = chr$(179) "|" = chr$(179).

MS SQL не делает различий между обоими символами. Я удалил chr$(124) а затем импорт по BCP работает нормально.

Ответ 6

Откройте файлы в блокноте ++. GO to View tab- > show symbols- > показать все символы. Я также столкнулся с той же проблемой в .tsv files.one вкладке было неуместно.

Ответ 7

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

Ответ 8

Поздно, но все же: в моем случае я точно получил это

SQLState = 22001, NativeError = 0
Error = [Microsoft][ODBC Driver 11 for SQL Server]String data, right truncation

И проблема была в том, что схема изменилась. В целевой базе данных появилось два новых поля. После того, как я установил предыдущую схему, импорт завершился успешно.

Ответ 9

Потратив 4 часа, потратив кучу ошибок и ошибок, я обнаружил, что решение может быть таким же простым, как таблица, в которую вы импортируете данные, которая должна иметь подходящую схему для файла, который вы пытаетесь импортировать. пример: в моем случае. Я импортировал .csv с 667, aaa, bbb в таблицу со схемами int (4), char (2), char (2), вызывающими строковые данные, правое усечение.