We have the following 4 characteristics in a query for which the user creates new combinations:
- Account (restricted to 500 entries in the filter and does not include '#')
- Customer (unrestricted in the filter - 100 entries - and hence does include '#')
- Segment (unrestricted in the filter - 20 entries - and hence does include '#')
- Activity (unrestricted in the filter - 20 entries - and hence does include '#')
Cartesian product of the above: 20.000.000 combinations
The settings for 'Access Type for Result Values' and 'Filter Value 'Selection at Query Execution' are:
- Account: char combs + char combs
- Customer: char combs + char combs
- Segment: char combs + MD
- Activity: char combs + MD
Business requires the follownig check: If Account selected ends with '1' then a Customer must be provided (i.e. '#' not allowed). All other combinations are valid.
For this reason we have implemented IF_RSPLS_CR_METHODS~CHECK.
Based on above information it shall be noted that the cartesian product of all combinations (20 million) are allowed EXCEPT (xxx1,#,*,*) . Thus the number of valid combinations is rather close to 20 millions.
This construct works well UNLESS the user hits 'value help'/F4 in which case all hell breaks loose!
In that case IF_RSPLS_CR_METHODS~CREATE is invoked and here we have implemented the generation of the valid Account-Customer combinations (populating e_th_chas) which are very close to the cartesian product of 500.000 - to be precise exactly 500.000 minus (xxx1,#) .
The setting for the number of valid combinations for the infoprovider seem to work well for a few 100.000 combinations, but not more and with 20 million the application interrupts with message RSPLS_CR 027
At this point there seem to be only two alternatives:
- deactivate the CHECK for Account- Customer OR
- tell the user that they may not use F4
Any other suggestions out there?