Диспетчер отчетов SSRS: связанный отчет ведет себя странно, но SQL запросы работают нормально - PullRequest
Новая
       50

Диспетчер отчетов SSRS: связанный отчет ведет себя странно, но SQL запросы работают нормально

0 голосов
/ 15 января 2020

Я создал отчет (назовите его Первичный) и детализацию (назовите его Вторичный) в построителе отчетов. Каждый из них имеет оператор SQL.

При выполнении в SQL Server Management Studio операторы SQL работают должным образом.

Однако при загрузке Primary.rdl и Secondary.rdl в диспетчер отчетов (веб-интерфейс в Inte rnet Explorer) они не генерируют правильные данные при запуске.

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

Основной оператор SQL:

Этот оператор собирает кучу пользовательских данных из нескольких таблиц и проверяет, приемлемы ли их пароли. Он заполняет список пользователей, чьи пароли не прошли проверку. 

This is pseudocode so pardon inconsistencies in var names

with details as (
select u.userid
     , u.password
     , u.firstname
     , u.lastname
     , u.userdescription
     , u.status
     , u.lastlog
     , dbo.IsPassswordAcceptable(u.userid, u.password) as passStatus
  from masterListOfUsers as u
)
select d.*, p.datavalue
  from details as d
 left join passwordDetailList as p
    on p.keyvalue = d.passStatus
   and p.datatype = 'ERRORMESSAGE'
 where d.passStatus <> 1 
   and d.passStatus <> -5 
   and d.status = (@USERSTATUS) -- only user ids in use
     ;

Вторичный оператор SQL:

Этот оператор является детализацией , Человек, управляющий отчетом, может щелкнуть по идентификатору пользователя в приведенном выше списке. Детализация выполняется при заполнении контактной информации для этого идентификатора пользователя. 

This is pseudocode so pardon inconsistencies in var names

   SELECT 
      m.userid 
    , c.address
    , c.city 
    , c.state 
    , c.zip 
    , c.cphone 
 FROM userMasterList AS m
left join userDetailList AS d 
   ON d.userid = m.userid 
left join anotherList as e on d.fullkey = e.fullkey 
left join yetAnotherList AS c 
WHERE m.userid = @USERID;

Ожидаемый результат:

Когда пользователь запускает Primary, список пользователей с плохими паролями. Можно щелкнуть по идентификатору пользователя каждого пользователя, после чего вторичный сервер заполняет информацию о местоположении / контакте, связанную с этим идентификатором пользователя.

Фактический результат:

При щелчке по идентификатору пользователя Вторичный не может заполнить любое местоположение / контактную информацию, связанную с идентификатором пользователя. Это происходит только иногда . В других случаях он работает нормально.

Я составил список этих «пустых» идентификаторов пользователя и запустил оператор Secondary SQL в Management Studio, и он заполняет все ожидаемое местоположение / контактную информацию.

Решения, которые я пробовал:

Я в полном замешательстве. Я трижды проверил операторы SQL и протестировал их в Management Studio. Я заново загрузил оба .rdl файла в диспетчер отчетов. Я переназначил вторичное устройство на первичное с помощью параметра «Создать связанный отчет» в диспетчере отчетов и ТАКЖЕ в параметре «Построитель отчетов»> Go В отчет.

Что еще можно сделать?

Ответы [ 2 ]

2 голосов
/ 15 января 2020

Это не совсем ответ как таковой, но список вещей, с которыми я бы работал в той же ситуации.

  1. Запустите SQL Профилировщик, чтобы отследить ваш сеанс отчета и сделать уверен, что выполняемый запрос - это то, что вы ожидаете. В зависимости от того, как параметры передаются в операторы SQL, SSRS не всегда будет делать все так, как вы ожидали.

  2. Проверьте, не можете ли вы повторить проблему, просто выполнив упражнение отчет самостоятельно (не через основной отчет)

  3. Определить, соответствует ли проблема указанным c идентификаторам пользователей? то есть всегда ли пользователь A терпит неудачу, а пользователь B всегда работает? Если проблема постоянна, проблема, скорее всего, связана с данными. Проверьте наличие специальных символов в полях, которые кажутся пустыми, например chr (13) / chr (10), возможно, они просто принудительно вставляют «реальный» контент в новую строку внутри текстового поля.

  4. Добавьте некоторую отладочную информацию в ваш отчет, чтобы помочь выявить проблему, такую ​​как:

    a. Отредактируйте запрос к набору данных, чтобы добавить дополнительную информацию из самого набора данных SELECT .... , c.addrees, len(c.address) as AddresLen from .... Вы можете добавить это к копии вашего отчета

    b. Добавьте другое текстовое поле, которое делает то же самое, но напрямую в SSRS (например, выражение будет выглядеть примерно так: =LEN(Fields!address.Value)). Затем у вас есть два числа для сравнения с тем, что вы видите. Если в текстовом поле LEN указано 20, но поле адреса выглядит пустым, проблема может заключаться в специальных символах.

0 голосов
/ 15 января 2020

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

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

Фиксированный вторичный оператор SQL:

Это псевдокод, поэтому извините за несоответствия в именах переменных 

SELECT 
      rtrim(m.userid) as userid 
    , rtrim(c.address) as address
    , rtrim(c.city) as city 
    , rtrim(c.state) as state
    , rtrim(c.zip) as zip 
    , rtrim(c.phone) as phone 
FROM userMasterList AS m
left join userDetailList AS d 
  ON d.userid = m.userid 
left join anotherList as e on d.fullkey = e.fullkey 
left join yetAnotherList AS c 
WHERE ltrim(rtrim(m.userid)) = ltrim(rtrim(@USERID));
...