Dynamics Community Forum Thread Details

System Message 7011: ROI Get RIPARAM Failed for Reporting: Error 56019

I'm running Dynamics SL 2015 on Windows Server 2016 MS SQL 2014

Im from Mexico and I have a local solution that makes invoices into xml and pdf formats in order to attend fiscal regulations. I have this report that if a execute directly from my report window, everything goes Ok, but when I call it from my local solution (that is integrated with SL) it crashes like this:

I have tried everything:

Several things from Crystal Reports, like Printer option, formulas in Record Selection, I have added RptCompany
I have reviewed ODBC connection, security permissions in folders where files are exported, in fact xml file is right there, so there is not a permissions issue.
I have reviewed that .dll are up to date

and you know what was the most funny thing? Some instances worked, so I'm in shock because, it stoped working suddenly...

I'm really desperate, as this is my final step at the sales cycle and my sales people is very angry at this....

Any advice?

In fact, the string showed doesn't seem to be a valid CR formula. I miss the curly brackets. Did you try the following expression instead?

{XEInvcData.RefNbr}='GU007110'

The "one-liner" definition of a Selection Formula is that of an expression that is added to the WHERE SQL clause. But that's to put it simple.

The selection formula really gets locally parsed inside the CR engine. It's expressed in a hybrid language that is either a Pascal-ish or a VB-ish dialect, hence the curly bracket thing. CR then tries to extract elements from the expression that can be mapped to the SQL WHERE clause. Elements that can't be pushed to the SQL query turns into run-time filters that CR uses to discard rows on the client end.

Other things to check:

See if there's already a record selection formula in the report definition already. It's a common place where a programmer leave unwanted debugging-time code.
Generally speaking, the CR engine will try to AND the run-time supplied selection formula with the one already in the report definition. There are language caveats and string size limitations for which this may not work and result in a ill-formed expression.
As a rule, always try to keep selection formulas as simple as one could get. Avoid adding join expressions, data partitions or complex language constructions.
ROI runs in a hybrid SQL impersonation. The report pre-run tasks are executed in the caller user context, but the report itself is run under the so called "SL Report User", which is named something like "E8F575915A...". This is a user with low access rights. This can be pretty annoying, since most programmers and DBA will check the end user rights over and over and see nothing wrong. There's a small chance that the error is due to a SQL access problem. SL provides a database utility that will ensure the Report User has the proper rights.

Quick Links

Leaderboard > Finance | Project Operations, Human Resources, AX, GP, SL