Buggy behaviors in RB make users give up (especially less-technical business users who this tool was designed for). The rest of us just get angry. These include: - Sometimes (inconsistently), pressing Enter will close the expression window and other time is adds a carriage return. - VB functions are (sometimes) translated to full-qualified object references which confuses users. - Certain field properties are changed when a data region is copied and pasted (example .UniqueName is changed to .Value) - Expression window just hangs & then crashes.
4 Comments
- Sorry Paul, but personally I would prefer if RB was discontinued, and effort put into other SSRS or BI features. IMO It's a massive duplication of features/code (vs Report Designer in Visual Studio) and and of little practical use.
- After posting this, an example surfaced in a project I'm working on. In the expression editor, I entered: "=CINT(Fields!Week_of_Year.Value)" and then at some point, the editor has replaced my expression with: "=Microsoft.ReportingServices.RdlObjectModel.ExpressionParser.VBFunctions.CINT(Fields!Week_of_Year.Value)". If this were a more complex expression with embedded functions, it would be unreadable. If the simple form for the expression is acceptable, please don't modify my code. When this happens to new users and students in a class, it really freaks them out.
- I believe report builder should be web based and not require a windows ad account to use. It should work with claims or oauth. The fact it is not a web based designer makes it hard for end users to leverage. Reporting is different than analysis and all users aren't devs who have visual studio
- Status added:New
Recent ideas
executeDaxQueries-like API call with effectiveUserName on SSO-enabled model with Service Principal
Please provide a way for a service principal to execute DAX - with an effective user name - against an SSO-enabled directlake semantic model and get per-user results that respect lakehouse OneLake Se...
