Urgent: New ReportPro 3 error, how to suppress it
Posted: Thu Mar 08, 2018 2:43 am
Hello X# Team,
I have annoying behavior of "new" ReportPro which is quite so strict on catching invalid relationship. It was working great with prior version of RP3 and got no problems as to the integrity of the report. It so happens that Index expression is lot longer than the Child Expression. or index tax expression do have fields that child do not have or tail end of the expression, child table no longer have equivalent.
For example: the example, the controlling order tag has the following expression: ACCT_NO +DOC_NO +SL_CODE +SEQ_NO, but the relationship is only required to be ACCT_NO +DOC_NO +SL_CODE because the child table do not have SEQ_NO field.
When I edit the report to follow new RP3 ways of validating relationship and when the data is completely hidden, I got ADS 5020 error which signify that index and table are not on same location, which I understand something about the RP3 not having to be used the index tag that I need to remove it to make the Child Expression editable.
Things works when table are visible from client PC but when it is hidden which is the case of all our clients, the report trigger an errors related to invalid expression or 5020 because report created index on the fly and it was accessible due to the design of our report which uses an array of all table location, index, etc..
So, to make less confusing: see attachment:
It took me months to pin down the true nature of the problem. I reiterate, previous build of RP3 do not generate an error when Index Tag have expression that are not fields of child table. In this case, I want this validation intact but I want to be able to "edit" the Child Expression.
Hope you understand.
Got no option to return to previous RP3; otherwise I will take another rounds of upgrade for hundred location all over the country which is logistically challenging for us to do in time allows.
For now, I will be editing again all reports to return to previous version and inform our users of the annoying but harmless error, see attachment number 2. Regards,
Rene
I have annoying behavior of "new" ReportPro which is quite so strict on catching invalid relationship. It was working great with prior version of RP3 and got no problems as to the integrity of the report. It so happens that Index expression is lot longer than the Child Expression. or index tax expression do have fields that child do not have or tail end of the expression, child table no longer have equivalent.
For example: the example, the controlling order tag has the following expression: ACCT_NO +DOC_NO +SL_CODE +SEQ_NO, but the relationship is only required to be ACCT_NO +DOC_NO +SL_CODE because the child table do not have SEQ_NO field.
When I edit the report to follow new RP3 ways of validating relationship and when the data is completely hidden, I got ADS 5020 error which signify that index and table are not on same location, which I understand something about the RP3 not having to be used the index tag that I need to remove it to make the Child Expression editable.
Things works when table are visible from client PC but when it is hidden which is the case of all our clients, the report trigger an errors related to invalid expression or 5020 because report created index on the fly and it was accessible due to the design of our report which uses an array of all table location, index, etc..
So, to make less confusing: see attachment:
It took me months to pin down the true nature of the problem. I reiterate, previous build of RP3 do not generate an error when Index Tag have expression that are not fields of child table. In this case, I want this validation intact but I want to be able to "edit" the Child Expression.
Hope you understand.
Got no option to return to previous RP3; otherwise I will take another rounds of upgrade for hundred location all over the country which is logistically challenging for us to do in time allows.
For now, I will be editing again all reports to return to previous version and inform our users of the annoying but harmless error, see attachment number 2. Regards,
Rene