Is there a way to pass a HOLD file created in a summary report to a drill down detail report?

I'm using stylesheets, which EXECUTEs the drill-down detail report rather than INCLUDEs.

WF 7.1.1
UNIX

Thanks!

The quick answer is no, but there are ways around it.
The problem is that you're executing a separate second request with a non-persistent connection. So the only things that can be passed, per se, are parameter values. You could try something like an accordian report or Active HTML report (separate license required) to provide all of the data in summarized form the first time around so as to avoid having to run a second drill-down.
Another option is to hold the file somewhere other than the default temporary directory or SET TEMPERASE=OFF, but then you have to deal with issues like multiple users, accessing the wrong agent temp directory, naming the hold files uniquely, etc. It gets really ugly really quickly.

A hold file has to be held on the server*. The issue is to ensure that every user would have their own version of the hold file, which means naming it in a manner to achieve this and placing it in a 'permanent' directory, rather than the agents temporary area.

This type of naming has been covered here before, and someone, I think Francis, had an excellent example which you can research.

(* Theoretically, I've never tried it, you could pass the whole of the data to the browser, but that is a bit of overkill I think)

I figured as much. Unfortunately, I don't believe we can get the server permissions to create a distinct folder/name convention.

I did try an example shown in an earlier post that involved UNIX 'makdir' and 'at' commands but we don't have those permissions.

Thanks for your suggestions just the same.

It sounds like you've probably already eliminated this as an option, but just thought I'd mention that what Alan is suggesting is something that we do quite regularly for exactly the reason you're asking.

One option would be to "precreate" those directories using an account that does have those permissions. Obviously this becomes a bit of a maintenance hassle because as you add/remove users, you have to go back and make/remove those directories. Obviously everyone's security standards are different, but in our case, the account that our services run under is an admin on the box, so it does have permissions to create those directories -- you might want to check on the possibility of getting that changed on your end.

Honestly, this method of holding files out to a user-specific folder works very VERY nicely for presenting the user a summary report and then drilling down to the details for the same criteria. Much prettier/faster than reretrieving the data from the database server in most cases... We use it quite extensively here.

Trav,

Though something I've never had to do, would it be possible to use a filename generated from a random number + time +/- userid +/- filename and place the files in one existing directory. I know that some maintenenca would be needed to clear up later, but it may work. Sometimes anything is better than re-extracting data constantly.

You might also prepend the userid to the name of the hold file to differentiate it from other simultaneous users and use APP HOLD to insure that the hold file in persistent.

quote:

Originally posted by Alan B:
Trav,

Though something I've never had to do, would it be possible to use a filename generated from a random number + time +/- userid +/- filename and place the files in one existing directory. I know that some maintenenca would be needed to clear up later, but it may work. Sometimes anything is better than re-extracting data constantly.

Good suggestion. I'd even go one more step and include the date and then you'd "never" have to worry about a duplicate file name...