Это сообщение об ошибке, которое я получаю после обработки куба SSIS
Errors in the back-end database access module. The size specified for a binding was too small, resulting in one or more column values being truncated.
Однако это не дает мне никаких указаний на то, что привязка столбца слишком мала.
Как это отладить?
RefreshЭто сообщение об ошибке сводило меня с ума в течение нескольких часов. Я уже нашел, какой столбец увеличил свою длину, и обновил таблицу данных в источнике, которая теперь показывала правильную длину. Но ошибка постоянно выскакивала. Оказывается, это поле использовалось в ссылке «факт-измерение» на вкладке «Использование измерения» куба. И когда вы обновляете источник, привязка, созданная для этой ссылки, не обновляется. Исправление состоит в том, чтобы удалить (изменить тип отношения на «Нет отношения») и заново создать эту ссылку.
Upd: поскольку этот ответ все еще актуален, я решил добавить скриншот, показывающий область, в которой вы можете столкнуться с этой проблемой. Если по какой-либо причине вы используете строку для связи измерения с фактом, на нее может повлиять увеличенный размер. А решение описано выше. Это дополняет проблему со столбцами «Ключ», «Имя» и «Значение» в атрибуте измерения. 
ESC правильный. Установите помощник BIDS из CodePlex. Щелкните правой кнопкой мыши папку «Измерения» и запустите проверку несоответствия данных.
Проверка несоответствия типов данных
Это исправило мою проблему.
Альтернативное исправление № 1 — SQL Server 2008 R2 (не пробовал в 2012 году, но думаю, что это сработает).
Альтернативное исправление № 2
<DataSize>100</DataSize>Как отметил Esc, обновления размера столбца могут повлиять на использование измерения в самом кубе. Вы можете либо сделать, как предлагает Esc, либо напрямую отредактировать файл *.cube — найти обновленный атрибут и соответствующий элемент размера данных: <DataSize>100</DataSize>
Я пробовал оба исправления при изменении размера столбца, и они оба работают.
В моем случае проблема заключалась в работе куба на живом сервере. Если вы работаете с кубом вживую, при подключении к серверу появляется это сообщение об ошибке. Но когда вы работаете с кубом как с решением, сохраненным на компьютере, вы не получаете сообщение об ошибке. Так что работайте над кубом локально и развертывайте его после внесения изменений.
В моем конкретном случае проблема заключалась в том, что мой запрос читал из Oracle, а жестко запрограммированный столбец имел завершающий пробел (моя ошибка).
Я удалил завершающий пробел и, на всякий случай, присвоил жестко заданному значению значение CAST ('MasterSystem' as VarChar2(100)) as SOURCE.
Это решило мою конкретную проблему.
Я столкнулся с этой проблемой. Вопрос решился удалением начальных и конечных пробелов и функций rtrim и ltrim.
Я столкнулся с той же проблемой, обновление источника данных не сработало. У меня было материализованное ссылочное измерение для раздела фактов, которое выдавало мне ошибку. В моей среде DEV я снял флажок Materialize и обработал раздел без ошибки.
Как ни странно, теперь я могу включить Materialization для той же связи, и она все равно будет обрабатываться без проблем.
Простая вещь, которую нужно попробовать в первую очередь - у меня это случалось несколько раз за эти годы.
Как уже упоминалось, причиной могут быть и данные с конечными пробелами. Проверьте их: SELECT col FROM tbl WHERE col LIKE '% '
Столкнувшись с той же проблемой, ответ от Esc также может быть решением. Причина гораздо более «скрыта», и более очевидные решения «Обновить» и «Проверка несоответствия типа данных» в моем случае не приносят никакой пользы.
Я не нашел правильного способа «отладки» этой проблемы.
