we created a graph and a grid report on the composer. Data for these graph and report comes from the same hold file which takes a long process to assemble. Rather than each graph and report goes through the same process to create this hold file, is there a way to create this hold file in the composer so that both can use? I am not looking for a pre-executed report caster job to create this file in advance on a regular basis.

This message has been edited. Last edited by: Kerry,

Not sure if this works but how about trying an embedded procedure option.

I am not sure I understand. The graph and the report are each an imbedded proc. I don't think we know which one proc is going to be executed first. So, if I have the graph to include the creation of the hold file, the report might be the one to run first and would not have the hold file yet. And vice versa.

How about making the file up to the hold file as an include file and then include it in the compound layout doc composer?
Make your graph and the report with the hold file name as separate fexes and include them as the report components in the compound layout. I think that would work.

what do you mean by "include the include file in the compound layout doc composer"? please explain.

I think what you want is to hold it locally (APP HOLD ...) under a specific name (ON TABLE HOLD AS ...)?

For example:

APP HOLD ibiwork

TABLE FILE CAR
PRINT CAR
BY COUNTRY
ON TABLE HOLD AS CARCNTRY FORMAT FOCUS INDEX COUNTRY
END
-RUN

TABLE FILE CARCNTRY
PRINT *
END

GRAPH FILE CARCNTRY
SUM CNT.CAR
BY COUNTRY
END

mike, while going through the development of your report/graphs in Composer, you can first pre-generate the HOLD file and keep it in an app folder so you have easy access to it. Borrowing from Wep5622's post:

APP HOLD ibiwork

TABLE FILE CAR
PRINT CAR
BY COUNTRY
ON TABLE HOLD AS HDATA
END
-RUN

You can now use HTML composer and all internal tools to "paint" your reports, graphs and the like out of that HOLD which is always there. This will save you some good chunk of development and debugging time.

Now, when you're ready to deploy, you can create a wrap procedure where you will create a similar HOLD file in EDATEMP (to allow for session concurrency) loading the HTML page right after.

-* Wrap procedure to create HOLD data and load HTML page
TABLE FILE CAR
SUM
DEALER_COST
BY COUNTRY
BY CAR
ON TABLE HOLD AS HDATA
END
-RUN

-HTMLFORM my_report_and_graph.htm

You can then deploy that .fex to your users instead of providing them with direct access to the HTML page.

1. I am not sure I understand the reason for a second table file in the wrap proc
2. but, as I indicated in the beginning that I don't want to use the approach to pre-create a hold file separately way ahead of time (pre-deployment). I want that file created during the request because data can change. If I create the hold way way ahead of time, the data will be different.

This message has been edited. Last edited by: mike,

That's why I split my advise in 2 stages.

For DEVELOPMENT only, you'll create your HOLD file ahead of time and save it somewhere where you (developer) can always see it. You don't have to refresh it everyday or ever for that matter. All you need is a data source + mastefile that can be used in your report/graph development within HTMl composer.

Now, for PRODUCTION, you say that you don't want to generate the file ahead of time (via Report Caster or otherwise) but the HOLD file still has to be refreshed *before* your report and graph get displayed everyday, hasn't it?

That's what the wrep .fex procedure does. It will guarantee that the HOLD file is generated everytime the report/graph request runs. You cannot use the old HOLD file created above because that was just to be used for development -- no data refresh on that one.

Just to add on this, the wrap procedure will indeed to what you want which is:

quote:

I don't want to use the approach to pre-create a hold file separately way ahead of time (pre-deployment)

And you won't have to. The HOLD file I advised to create first will only exist in your Development environment, not in Prod. For prod, you want a fresh HOLD file everytime.

Since you don't want to create it ahead of time (I don't see why that would be a problem but it's your requirement anyway) you have to link its creation/refresh process to the report execution itself. That's why a wrap is needed. It's the only way to serialize the processing so the HOLD file gets there first, and then the report and graph can run in parallel as they do when embedded in HTML created with composer.

now I see. I think that might work. Thanks!