No, I Will Not Fix Your #@$!! Computer → [Windows] SQL Report Builder where type expression

I have two datasets, PickDetails and RegisteredUsers, I've been trying to print the value of Name, "RegisteredUsers" where value of BadgeID, "PickDetails" and BadgeID, "RegisteredUsers" match.

I've tried different expressions using lookup, iif, and sum, but only been able to get BadgeID and not the name.

Thank you for your help.

Can you post some examples of the SQL which isn't working?

=iif(First(Fields!BadgeID.Value, "PickDetails") = ((Fields!BadgeID.Value, "RegisteredUsers"), "@Name", "RegisteredUsers", "Unknown Badge"))

I don't think iif is going to work well here. Have you looked at LookupSet()?

Or, if possible, you should do the join SQL-side. Much faster and probably a simpler implementation.

I ended up making another dataset to query the information.

SELECT [Name]
FROM
  dbo.RegisteredUsers, dbo.PPS_Parts
WHERE dbo.PPS_Parts.BadgeID = dbo.RegisteredUsers.BadgeID and dbo.PPS_Parts.ID = @PickID
 

[Name] shows fine when I run it in Report Builder or via the web UI, but when the end user presses the key combo on their Motorola scanner, which edits values in the PPS_Parts table and causes RDLC to fire off and pass the value of PPS_Parts.ID to the Report Service, it doesn't print the name...

The Sr. Dev changed the main dataset to have

FROM            PPS_Parts INNER JOIN
                         RegisteredUsers ON PPS_Parts.BadgeID = RegisteredUsers.BadgeID
WHERE ID = @PickID
 

...but now the whole report shows blank when it prints, but not via the Report Builder or the web UI when entering the PickID.

May just have to do it how the other Sr. Dev wanted to, have an extra var @UserID be passed when the report is called.

This probably doesn't apply in your case (I haven't actually checked), but it's something that you need to be aware of, because I've been burned by it before myself. I've used various implementations of SQL on difference platforms over the decades, and in some of them words like USER and ID and such might actually be reserved words which have a special meaning in that implementation. This usually leads to situations where the SQL itself appears to be correct (no errors), but you just don't get the results that you expect to get.