Ошибка импорта SQLISIS: столбец протокола PROGRESS openge в таблице имеет значение, превосходящее его максимальную длину или точность

Я импортирую данные из базы данных прогресса.

Я получаю следующую ошибку:

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

Есть ли способ указать конкретную длину данных столбца выбора в инструкции select?

Например: SELECT SUBSTRING(EMAIL,15) FROM SQL92.PROGRESSTABLE

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

У меня нет доступа к базе данных Progress, поэтому я не могу запустить DBTool для исправления данных.

Здесь задавали тот же вопрос, но решение никогда не было опубликовано. Могу ли я определить идентификаторы длины столбца IDataReader?

2 ответа

Ответ здесь:

ODBC Error "Столбец x в таблице y имеет значение, превышающее его максимальную длину или точность"

Используйте этот фигурный синтаксис, чтобы запустить собственную функцию RDBMS (Progress) и исправить данные до того, как они попадут в ODBC:

SELECT { fn CONVERT(SUBSTRING( EMAIL,1,15) , SQL_VARCHAR) } 
FROM SQL92.PROGRESSTABLE

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

Как некоторый фон, вы, вероятно, столкнетесь с двумя типами ошибок, если используете SSIS против Progress:

<blockquote>

Тип данных "выходной столбец" xyz "(n)" не соответствует типу данных "System.Decimal" исходного столбца "xyz"

(Может быть любой тип данных)

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

Кратковременное решение - открыть пакет и обновить метаданные, дважды щелкнув по источнику

Другая ошибка:

<blockquote>

Столбец xxx в таблице yyy имеет значение, превышающее его максимальную длину или точность.

Это означает, например, что в базе данных есть данные длиной 371 символ, но данные dicitionary говорят, что его 324 символа длинны.

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


Длина данных для данных SQL, полученных из соединения ODBC, определяется свойством "Ширина" полей базы данных Progress. Доступ к нему можно получить через "Словарь данных о ходе выполнения", выбрав нужную таблицу, затем выбрав в строке меню "Параметры", "Настроить ширину поля". Обычно в полях CHAR свойство "Ширина" определяется со значением, которое соответствует удвоенной ширине "Формат".

Например: поле FOO, тип CHAR, формат "x (20)" по умолчанию имеет 40 значений ширины SQL, в два раза превышающих формат оригинального формата.

Несмотря на то, что вы можете записывать данные длиной более 20 символов в поле CHAR, отформатированное как "x (20)", пока Progress не заботится о том, какое количество данных, хранящихся в его полях, и фраза "Формат", предназначено только для отображения (конечно, в пределах его ограничений по типу данных), он ограничивает длину данных для SQL-соединений с жестким пределом, например, Oracle. Другими словами, если вы не можете писать символы N + n в поле базы данных Oracle, определенном как длина N, вы не можете извлекать данные из базы данных Progress через соединение ODBC, если они определены как формат " x (N) ", и данные, хранящиеся на нем, превышают, типично, 2N.

Если у вас нет доступа к базе данных Progress, вы можете связаться с лицом, ответственным за данные, хранящиеся в базе данных Progress, и попросить его изменить размеры полей схемы базы данных в соответствии с полным объемом хранимых данных. Программы, хранящие данные в базе данных, могут быть несогласованны с размером поля базы данных. В противном случае вы не сможете извлекать данные из таблиц с полями, в которых хранится больше символов "Ширина".

licensed under cc by-sa 3.0 with attribution.