| Multiple Parameter Handling [message #117270] |
Tue, 26 April 2005 03:33  |
weekend79
Messages: 198
Registered: April 2005
Location: Islamabad
|
Senior Member |
|
|
(Let’s consider my problem with known damobld (scott/tiger) database)
A report having following User Parameter:-
P_1 (to select department #)
P_2 (to select job)
I wish when I select P_1 and then move to P_2.
P_2 only shows jobs which are in selected department of P_1.
i.e. If I select 10 in P_1. P_2 will only shows (MANAGER, PRESIDENT, CLERK)
I code following in P_2 (Parameter List Of Values)
Select all EMP.JOB from EMP
where
EMP.DEPTNO = nvl(P_1, EMP.DEPTNO)
But code won’t compile and give following error give following error in (Parameter List Of Values)
REP-0781: Bind variables are not allowed in the Select statement.
Please advice how to do as if it won’t work it will be foolish to offer other job to user in P_2 + I will not give any report if some one select other jobs.
Wishes
Jawad
|
|
|
|
|
|
|
|
| Re: Multiple Parameter Handling [message #117330 is a reply to message #117270] |
Tue, 26 April 2005 09:53  |
Steve Corey
Messages: 336
Registered: February 2005
Location: RI
|
Senior Member |
|
|
Reports does not really allow (at least to my knowledge) this type of flexibility within its parameter form. The use of a simple custom form in this specific case is probably your best bet assuming that you will be running it in client/server mode (as opposed to WebForms and the internet Application Suite). If you will be registering the form for use on the web, there is another approach you can use that works similarly to the form approach but without the design of a custom form (using descriptive flex field manipulation). But since you haven't stated what you will be doing with the form, I won't assume that this is your environment.
Also, it is important that the end-user understands the application and what they are doing. As a developer you have only so much control with the tools you are given. You (or your boss) has to decide if it is worth the investment of time and resources to filter the second parameter. I have come to find that if the end-user can't use the application or doesn't understand it, it won't matter how well its designed, they will still find a way to screw up the information they are trying to get. I think it is imperative that the user be well-versed (either through documentation or training) in how to get meaningful output from a complex system. You only provide the means to do it.
HTH,
Steve
[Updated on: Tue, 26 April 2005 09:56] Report message to a moderator |
|
|
|
|
|
| Re: Multiple Parameter Handling [message #117670 is a reply to message #117270] |
Thu, 28 April 2005 16:05 |
Steve Corey
Messages: 336
Registered: February 2005
Location: RI
|
Senior Member |
|
|
Jawad -
I know what you mean about wanting to make the form as simple as possible for the end-user. There are some cases however (this may be one of them) where the resources spent on accomplishing something is just not worth it when you can tell the end user 'Make sure to use VALID combinations. If you combine two values that don't make sense, you won't get the information you are looking for.' That decision is up to either you or your supervisor, I am just offerring an opinion on the situation. If you do need a custom form to do this, I do have examples, so let me know what you want to do.
HTH,
Steve
|
|
|
|
|
|
| Re: Multiple Parameter Handling [message #117799 is a reply to message #117270] |
Fri, 29 April 2005 11:54 |
Steve Corey
Messages: 336
Registered: February 2005
Location: RI
|
Senior Member |
|
|
Jawad -
Before I give you the custom form example of how to call a report from forms, I'll need to know a couple of things, so please private message me with the following information:
1. Oracle Database Version (10g, 9i, 8i, etc.)
2. Developer Suite Version (6i, 9i, etc)
3. Whether or not you are using the ERP modules (aka WebForms
user-interface)
Steve
|
|
|
|
| Re: Multiple Parameter Handling [message #122423 is a reply to message #117270] |
Mon, 06 June 2005 08:19 |
rockysh
Messages: 4
Registered: June 2005
|
Junior Member |
|
|
Hello,
Thanks for the input. It was very usefull to me.
I would like to know is it possible to pass a dynamically created select statement to replace the query of the report ?. I tried DATA_PARAMETER in RUN_PRODUCT, but this requires the column/data match with the report query and the record_group query.
I am trying to build a form where the user will be able to select the columns he wants from the displayed data and print using reports.
All help will be greately appreciated.
Cheers
|
|
|
|
| Re: Multiple Parameter Handling [message #243222 is a reply to message #117270] |
Wed, 06 June 2007 08:47 |
winnie_e
Messages: 2
Registered: April 2007
|
Junior Member |
|
|
hello i know that this topic is so old but do you now a solution for this problem.
i am having the same trouble in my reports too.
how can i solve it.
i don't want my end user to use a form for it.
|
|
|
|
| Re: Multiple Parameter Handling [message #337498 is a reply to message #243222] |
Thu, 31 July 2008 01:51 |
rakhatmis
Messages: 25
Registered: March 2008
|
Junior Member |
|
|
hello all
i know this message is very old but can anyone tell me the solution for this problem as i am also facing the same problem of multiple parameter handling. if anyone knows the solution, please help me
|
|
|
|
| Re: Multiple Parameter Handling [message #337508 is a reply to message #337498] |
Thu, 31 July 2008 02:13 |
 |
Littlefoot
Messages: 21823
Registered: June 2005
Location: Croatia, Europe
|
Senior Member
Account Moderator |
|
|
A working solution has been suggested by Hsinghalmrt - create your own parameter form using Forms Builder; it will allow you to create List of Values which can be dependent on a previously selected value.
However, one of our members (not very active one, though) has said that he/she managed to do that in Reports Builder, using Java code. As he/she never bothered to post the whole solution (although people did request it), along with me being unable to produce any kind of Java code - sorry.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
