2011-01-17 2 views
2

Это многоугольные вопрос, но любая помощь ценитсяSharepoint бизнес-данных Поведение

фона:

  1. У меня есть определение приложения 6 объектов, использующих единый вход
  2. База данных обратно конец Firebird через ODBC
  3. Все данные поступают из хранимых процедур

Quest Ионы:

1 При попытке реализовать одно или любое из объектов из BDC в веб-части списка бизнес-данных я получаю следующую ошибку: «Произошла ошибка при извлечении данных из. Администраторы, см. Журнал сервера для получения дополнительной информации. "Это происходит только тогда, когда у меня есть поля, которые являются нулевыми, в этом случае это поле, которое было объявлено как строка.

2.Когда я проверяю журналы, это Система. OverflowException.

3.Если я изменить его таким образом, выход из процедуры является пустая строка, я вдруг получить «Названное свойство объекта устанавливается недопустимое значение»

4.The ошибка из журналов после изменения на пустую строку: «Исключение передано в HandleXslException.HandleException System.ArgumentException:«. », шестнадцатеричное значение 0x00, является недопустимым символом« Что дает? Он работал прошлой ночью без пока не появится запись с нулевым значением в одном из полей строки. Теперь даже замена нулевого значения на что-то общее все еще дает мне свойство title недопустимой.

Самое недоумение: если я изменяю запрос, чтобы строки с тем, что было бы пустой или пустой строкой, не были в запросе, ошибка исчезнет. Но если я добавлю их обратно и заменим нулевую строку на что-нибудь, ошибка вернется. Что такое @ @ $? Как он знает, что я заменил нулевое значение чем-то еще до того, как записи будут возвращены в XmlReader?

+0

В случае, если кто-то другой сталкивается с этой проблемой: я установил кодировку как Юникод на всех выходах varchar и char, и он исправил это. Отсутствие кодировки приводило к тому, что для этого столбца были нулевые символы (а не нулевая запись, но один нулевой символ), а Sharepoint не смог разобрать поле. Изменено кодирование, и все работает. – Sam

ответ

0

Я столкнулся с этим точным сценарием и привел некоторые сердитые/запутанные моменты. Как вы сказали в своем комментарии:

I set the encoding to be unicode on all varchar and char outputs and it fixed it. The lack of encoding caused there to be null characters (not a null record, but one null character) for that column and Sharepoint could not parse the field. Changed the encoding, and everything works.

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

Смежные вопросы