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" 选项将辅助节点重新分配给主要节点。
我还能做什么?
这并不是真正的答案,而是我在相同情况下会做的事情的清单。
运行 SQL Profiler 跟踪您的报告会话并确保正在执行的查询符合您的预期。根据参数传递给 SQL 语句的方式,SSRS 不会总是按照您预期的方式执行操作。
检查您是否可以仅通过 运行 钻取报告本身(而不是通过主要报告)来重复该问题
确定问题是否与特定用户标识一致?即用户 A 总是失败而用户 B 总是工作吗?如果问题一致,则问题很可能与数据相关。检查显示为空白的字段中的特殊字符,例如 chr(13)/chr(10),它们可能只是将 'real' 内容强制到文本框内的新行。
在您的报告中添加一些调试信息以帮助确定问题,例如:
一个。编辑数据集查询以从数据集本身添加更多信息 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));
我在 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" 选项将辅助节点重新分配给主要节点。
我还能做什么?
这并不是真正的答案,而是我在相同情况下会做的事情的清单。
运行 SQL Profiler 跟踪您的报告会话并确保正在执行的查询符合您的预期。根据参数传递给 SQL 语句的方式,SSRS 不会总是按照您预期的方式执行操作。
检查您是否可以仅通过 运行 钻取报告本身(而不是通过主要报告)来重复该问题
确定问题是否与特定用户标识一致?即用户 A 总是失败而用户 B 总是工作吗?如果问题一致,则问题很可能与数据相关。检查显示为空白的字段中的特殊字符,例如 chr(13)/chr(10),它们可能只是将 'real' 内容强制到文本框内的新行。
在您的报告中添加一些调试信息以帮助确定问题,例如:
一个。编辑数据集查询以从数据集本身添加更多信息
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));