Я отследил это до устаревшего файла .xsd (DataSet) - где-то вдоль пути ширины строки столбца таблицы было увеличено, но DataSet не обновлялся и не восстанавливался, поэтому он все еще имел старый ограничение ширины для этого элемента, например, < xs: maxLength value = "50"/> в .xsd XML вместо новой ширины 125 символов. Ошибка была брошена для тех случаев, когда по крайней мере одна запись в подзаголовке имела значение данных (строка) в этом столбце, которое превышало старую ширину 50.
Важным ключом стало добавление обработчика для DataSet. Выбранное событие; Я уже использовал событие .Selecting, чтобы установить параметр суб-отчета (привязать его к родительской записи), но я не мог видеть ничего полезного при взломе этого события. Однако, рассматривая переменную args события в событии .Selected, после того, как выбор должен был произойти, я обнаружил исключение (исключение было вызвано целью вызова) с InnerException («Не удалось включить ограничения». более строк содержат значения, нарушающие непустые, уникальные или внешние ключи »). Также была трассировка стека, которая указывала, что точка отказа выполняла Adapter.Fill (dataTable).
Хотя это оказалось довольно вводящим в заблуждение - у меня не было таких ограничений на таблицах, участвующих в запросе за DataSet, - по крайней мере, я сосредоточил внимание на конкретных записях в подзаголовках. После многих бесплодных поисков аномалий в данных отчета subreport SQL Server Mgt Studio я в конце концов начал удалять записи один за другим из одного из случаев оскорбительных случаев, повторно запуская отчет каждый раз, чтобы увидеть, исправил ли я ошибку , В конце концов я удалил запись в отчете и отчет работал - появились оставшиеся записи в отчетах!
Теперь у меня была конкретная запись в подзаголовке для более тщательного изучения. Случайно (хочу, чтобы я мог назвать это вдохновенной интуицией ...), я решил отредактировать эту запись в веб-приложении, а не смотреть на нее, как я был на SQL Server. Одно из полей было отмечено предупреждением о том, что строковое значение было слишком длинным! Это было загадкой для меня на мгновение: если строковое значение было слишком длинным, как это можно было бы сохранить в базе данных ?! Я дважды проверил определение столбца в таблице и обнаружил, что он был длиннее, чем пытались обеспечить интерфейс веб-приложения. Затем я понял, что столбец был расширен без обновления пользовательского интерфейса приложения, и я сразу же подозревал, что файл .xsd также не был обновлен ... Bingo!
В этой истории, вероятно, есть много морали, и это оставляет мне знакомое и нежелательное ощущение, что я не делаю что-то разумно, как я должен. Одна мораль: всегда обновляйте (или лучше, а проще и просто, просто перестраивайте) свои файлы .xsd DataSet всякий раз, когда вы меняете запрос или таблицу, что на основе ... проще сказано, чем запоминается. Жестокое чувство, которое у меня есть, заключается в том, что я должен был понять, что я не понял, чтобы избежать создания хрупких приложений, где ширина столбца, определенная в базе данных, также отдельно кодируется в пользовательский интерфейс и/или код для обеспечения обратной связи с пользователем и/или проверка достоверности данных ... приветствуются предложения о том, как управлять этим более надежным образом!