SSRS 报告管理器:链接报告行为异常但 SQL 查询工作正常

SSRS Report Manager: Linked report behaving strangely but SQL queries work fine

我在 Report Builder 中创建了一个报表(称为主要)和一个钻取(称为次要)。其中每一个都有一个 SQL 语句。

在 SQL Server Management Studio 中执行时,SQL 语句按预期工作。

但是,当 Primary.rdl 和 Secondary.rdl 上传到 Report Manager(Internet Explorer 中的 Web 界面)时,它们在 运行 时不会生成正确的数据。

因此,我认为问题不在于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语句:

此语句是钻取。 运行 报告的人可以单击上面列表中的用户 ID。在填充该用户 ID 的联系信息的位置执行钻取。

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;

预期结果:

当用户 运行 成为主要用户时,会填充密码错误的用户列表。可以单击每个用户的用户 ID,这会触发辅助节点填充与该用户 ID 关联的 location/contact 信息。

实际结果:

单击用户 ID 时,辅助节点无法填充与用户 ID 关联的任何 location/contact 信息。这种情况只是有时。其他时候,它工作正常。

我在 Management Studio 中列出了这些 "empty" 用户 ID 和 运行 辅助的 SQL 语句,它填充了所有预期的 location/contact 信息。

我尝试过的解决方案:

我完全被难住了。我已经对 SQL 语句进行了三重检查,并在 Management Studio 中对其进行了测试。我已将两个 .rdl 文件重新上传到 Report Manager。我已通过 Report Manager 中的 "Create Linked Report" 选项以及 Report Builder 的 Action > Go To Report 选项中的 "Create Linked Report" 选项将辅助节点重新分配给主要节点。

我还能做什么?

这并不是真正的答案,而是我在相同情况下会做的事情的清单。

  1. 运行 SQL Profiler 跟踪您的报告会话并确保正在执行的查询符合您的预期。根据参数传递给 SQL 语句的方式,SSRS 不会总是按照您预期的方式执行操作。

  2. 检查您是否可以仅通过 运行 钻取报告本身(而不是通过主要报告)来重复该问题

  3. 确定问题是否与特定用户标识一致?即用户 A 总是失败而用户 B 总是工作吗?如果问题一致,则问题很可能与数据相关。检查显示为空白的字段中的特殊字符,例如 chr(13)/chr(10),它们可能只是将 'real' 内容强制到文本框内的新行。

  4. 在您的报告中添加一些调试信息以帮助确定问题,例如:

    一个。编辑数据集查询以从数据集本身添加更多信息 SELECT .... , c.addrees, len(c.address) as AddresLen from .... 您可以将其添加到报告的副本中

    b。添加另一个文本框,它直接在 SSRS 中执行相同的操作(例如,表达式类似于 =LEN(Fields!address.Value))。然后,您有两个数字可以与您看到的进行比较。如果 LEN 文本框显示 20 但地址字段显示为空白,则可能是特殊字符问题。

经过数小时的修补,问题最终是用户 ID 被一些查询工具而不是 SQL 语句本身删除了所有前导和尾随空格。所以在报表管理器中最终报表为运行时,查询数据时出现多余的空格,导致查不到数据

修剪数据点后,此问题已解决。

固定Secondary SQL语句:

这是伪代码,请原谅 var 名称中的不一致

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));