I would like to build a drill down menu based upon the results of another report, any clues or pointers would be greatly appreciated.

Oz,

Firstly, please update your signature as per Reminder on front page of this forum.

Secondly, look at using Dialogue Manager and multiple data passes?

T

Thanks Tony
Can you please expand on the multiple data passes coment?

The simple answer is , you can't drill down based upon what is in another report (unless you are talking about simply passing parameters from one report to the next). You can, however, create the data for the first report, then join to that data and create your drilldowns from there. This is what Tony was referring to - making a couple of passes against the data to get what you need for the drilldowns.

Oz,
A drill-down menu is built with a number of DRILLMENUITEM elements in the stylesheet. For example:

  
DRILLMENUITEM='Cost Report' ...
DRILLMENUITEM='Income Report' ...

So if you want to build your "drill down menu based upon the results of another report", you should manage to retrieve the results of your previous report in &variables so that you can code:

  
DRILLMENUITEM='&VAR1' ...
DRILLMENUITEM='&VAR2' ...

I hope this helps.

Thanks Darin for the clarification. My issue with that approach is that there are no fields that I can join to.

Thanks Danny, how does this method work with n number of variables?

Oz,

The number of variables is probably not an issue. For example, you could index the &variables. If you post a simple repro of your problem with one of the IBI files (CAR, GGSALES etc.), we could try to concoct a solution.

... and remember that it will only function on HTML output.

T

quote:

My issue with that approach is that there are no fields that I can join to

One of two things. Either
1. The data is completely unrelated in which case the question is how are you determining drilldowns when the data is completely unrelated to what is on your report?
OR
2. There IS a field you can join to, you just need to make some creative use of DEFINE-based joins or some nifty HOLD files.

As Daniel suggests, maybe an example to help us see what it is your are trying to do would be helpful.

Darin, in answer to your reply I'm number 1. what I have is a list of orders which can be cancelled. So I want to build for each cancellation code a drillmenu item which is going to pass the order and the cancellation code to a URL. I hope this explains it a little better.

Danny-SRL, thanks for your interest. in answer to you reply, if we had the CAR file as our main file and then a drill down showing all the employees from the employee master.

I'm glad to know you're number 1.

In your example, you would just have a second procedure for the employee report that is executed by clicking on a line in the car file and passing no parameters. I don't think this is what you are intending.

So to get this straight (we'll get there eventually) You're running a WF report that lists orders.
1. If you click on an order does it always send a cancellation request or is this just one of the things that could happen? (This determines a straight drilldown vs. multi-drill.)
2. Does the drill run a second WF request or is it just sending a URL string to some other place with the necessary parms? (This detemines the action of the drill - WF procedure vs. URL.)

Other questions (I'm sure) to follow--

Darin in answer to 1. It is just one of the actions. I would expect to see n cancellations reason without drilling out to another report. Number 2 just a URL string.

regards

So you create the drill to a URL as one of the multidrill items, passing whatever parameters (whether dynamic or static) are required for that URL.

Darin, so this brings me full circle, my paramaters are values in my unrelated file.

Do you know what those parameter values are at the time you run the report? They can't be variable by the record displayed because you say they are unrelated. That leaves them to be fixed, so if they're fixed, just set the parameter value as a constant in the first report and execute the drilldown. But this means that you get the same 2nd report/process running regardless of which record you click on in the first report.

not quite, they are not variable by the record displayed. There could however be 1 or 50 potential paramater values. Each one I would like to have as the drilldown menu item eg.
Number 1 cancel due to customer request
Number 2 cancel due out of stock...etc etc

Oz,

In the interests of moving forward, and as it appears that you are not keen to "jump in the water", try this code and see if you can understand it.

Note: All the code used here can be built using information gleaned from various documents, help files and the like. You only have to have the courage to get off of your ****, locate them and read them.

However, if you find that you cannot even follow the code example I give, then approach your management and ask them to send you on some basic training courses.

TABLE FILE EMPLOYEE
PRINT EMP_ID
   BY DEPARTMENT
ON TABLE SAVE AS OZIHOLD1 FORMAT ALPHA
END
-RUN
TABLE FILE CAR
SUM RCOST DCOST
 BY COUNTRY
 BY CAR
 BY MODEL
ON TABLE SET HTMLCSS ON
ON TABLE SET PAGE NOLEAD
ON TABLE SET STYLE *
  GRID=OFF, SIZE=9, $
TYPE=DATA, COLUMN=COUNTRY, 
-READ OZIHOLD1 &Dept.A10. &Emp_Id.A9.
-SET &Cnt = 1;
-REPEAT :Loop WHILE &IORETURN EQ 0;
     DRILLMENUITEM='Item &Cnt',FOCEXEC=yourdrilldown(Dept='&Dept' Emp_Id='&Emp_Id'),
-READ OZIHOLD1 &Dept.A10 &Emp_Id.A9
-SET &Cnt = &Cnt + 1;
-:Loop
$
ENDSTYLE
END

T

p.s. Let me know to whom you wish my invoice to be sent!!

Thanks Tony, believe it or not I had spent hours researching this before filing my case. This is perfect..

Oz,

If you notice, the example I gave you uses exactly what I suggested you did in the very first reply to your question. Most of the subsequent posts inferred the method to use, you just needed to try it out using actual code.

For future reference, and as a suggested pre-cursor, try and reproduce what you are trying to do using the sample data supplied with the "standard" install - CAR, GGSALES, GGORDER etc - so that folks can look at your code and run it to experience your question for themselves. It is also a suggested method before reporting a fault to Tech Support because, if you can show the problem on the sample data then it is likely that Tech Support can understand your problem quicker and thereby suggest a solution, work around or identify it as a real bug.

Don't be concerned that your code may not show exactly what you need provided it is very close, after all a picture paints a thousand words and running code to get an output provides that picture.

T

Tony
your absolutely right, your first post did tell me Ijust misunderstood it...must be your accent.......thx

What accent

T