Как исправить ошибки операции OLE DB с несколькими шагами в SSIS?

Я пытаюсь сделать пакет DTS для передачи данных между двумя базами данных на одном сервере, и я получаю следующие ошибки. Iv прочитал, что генерируемая ошибка с несколькими шагами OLE DB может возникать при переходе между различными типами баз данных, и есть потеря точности, но здесь это не так. Как просмотреть метаданные столбца?

Ошибка: 0xC0202009 в задаче потока данных, piTech [183]: ошибка OLE DB имеет произошло. Код ошибки: 0x80040E21. Запись OLE DB доступна. Источник: "Исходный клиент Microsoft SQL" Hresult: 0x80040E21 Описание: "Многоступенчатая операция OLE DB порожденных ошибок. Проверьте каждый OLE DB значение статуса, если доступно. Нет работы было сделано.".

Ошибка: 0xC0202025 в задаче потока данных, piTech [183]: невозможно создать OLE DB сбруя. Убедитесь, что столбец метаданные действительны.

Ошибка: 0xC004701A в задаче потока данных, DTS.Pipeline: компонент "piTech" (183) не удалось выполнить этап предварительного выполнения и возвращенный код ошибки 0xC0202025.

Ответы

Ответ 1

Взгляните на свойства полей (тип, длина, значение по умолчанию и т.д.), они должны быть одинаковыми.

У меня была эта проблема с SQL Server 2008 R2, потому что длина полей не равна.

Ответ 2

Эта ошибка распространена, когда исходная таблица содержит столбец TEXT, а целью является нечто иное, чем столбец TEXT. Это может быть настоящим людоедом, если вы еще не сталкивались (или не забывали!).

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

Ответ 3

Этот запрос должен идентифицировать столбцы, которые являются потенциальными проблемами...

SELECT * 
FROM [source].INFORMATION_SCHEMA.COLUMNS src
    INNER JOIN [dest].INFORMATION_SCHEMA.COLUMNS dst 
        ON dst.COLUMN_NAME = src.COLUMN_NAME
WHERE dst.CHARACTER_MAXIMUM_LENGTH < src.CHARACTER_MAXIMUM_LENGTH

Ответ 4

Эта проблема будет вызвана главным образом из-за пустых строк в конце файла, удалите их и запустите задание.

Ответ 5

Вы можете использовать SELECT * FROM INFORMATION_SCHEMA.COLUMNS, но я подозреваю, что вы создали целевую базу данных из script исходной базы данных, поэтому очень вероятно, что они будут одинаковыми.

Некоторые сравнения могут что-то принести.

Такие ошибки иногда возникают из-за попытки вставить слишком много данных в столбцы varchar.

Ответ 6

У меня была аналогичная проблема, когда я переносил данные из старой базы данных в новую базу данных, я получил ошибку выше. Затем я запустил следующий script

SELECT * FROM [source].INFORMATION_SCHEMA.COLUMNS src INNER JOIN [dest].INFORMATION_SCHEMA.COLUMNS dst ON dst.COLUMN_NAME = src.COLUMN_NAME WHERE dst.CHARACTER_MAXIMUM_LENGTH < src.CHARACTER_MAXIMUM_LENGTH

и обнаружил, что мои столбцы немного отличаются по размеру символов и т.д. Затем я попытался изменить таблицу на новую структуру таблицы, которая не сработала. Затем я передал данные из старой базы данных в Excel и импортировал данные из excel в новую БД, которая работала на 100%.

Ответ 7

Также проверьте, нет ли команды script без команд пакетного отсечения (удалите инструкции "GO" в одной строке).

Ответ 8

'-2147217887' message 'IDispatch error #3105' source 'Microsoft OLE DB Service Components' description 'Multiple-step OLE DB operation generated errors. Check each OLE DB status value, if available. No work was done.'."

Это то, с чем я столкнулся. Проблема возникла из-за того, что я сменил поставщика SQLOLEDB.1 на SQLNCLI11 без упоминания режима совместимости в строке соединения. Когда я устанавливаю этот DataTypeCompatibility=80; в строке подключения, я решил проблему.

Ответ 9

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

Ответ 10

У меня была эта ошибка при передаче csv в mssql Я преобразовал столбцы в DT_NTEXT и некоторые столбцы на mssql, где установлено значение nvarchar (255).

установив их на nvarchar (max), разрешив его.