Report url parameters

Question

I have a list item "My Reports" under "Reports" tab in the application. When this list item is active, it should show all the reports for that user.Using one of the many query screens (with bunch of parameters), the user will generate a report. The user should be able to give a name to this report and save it in the database as that particular users report. When the user logins next time, these reports should appear as hyperlinks when the user navigates to "My Reports" list item in the application. When the user clicks on any of the report links, the corresponding report should be displyed. How can I store the report url with all the parameters as a string in the database and display them as report links to the user?.
Thanks,
Surya

Answer 1

hey surya--
     i know that you and i already spoke about your hyperlink columns, but i'll just post that answer really quickly so others can follow:
because you opted to have a single report page that runs all of your users' stored queries, you were unable to take advantage of the links we allow you to generate after the fact as a column attribute. the work around for your approach was to code your htp.anchor calls right into your select statement that ultimately gets stored in your stored queries table. if you'd stored the individual report parameters instead of the query strings, you could direct users back to the custom report screen for each report. you'd then be able to use our column attribute linking.
...now onto remembering your users' sort-enabled column header preference...
you'd like your app to be able to remember the column by which your user last sorted his report so that he can then invoke his stored report using that same sort preference. it takes a bit of a hack to achieve this, but the approach certainly works:
if you create a report with sort-enabled column headers and click on the generated column headers, you'll find that we pass the sorting information back to the html db engine via the URL. the two bits of information that make this possible are the value for :REQUEST (the fourth value in our f?p= url syntax) and the fsp_region_id parameter that we tack onto the end of the URL. if you gather these two pieces of data, you can then construct a URL that would sort the resulting report the same way that your user last viewed it. the fsp_region_id part won't change for your report. it's the numeric id associated (behind the scenes) with your report region. you can get that number by clicking on your report region name from your page definition screen in the html db development environment. the last number in your URL that's shown on the resulting page is your region id. the value of :REQUEST is a little trickier to trap, but it's still doable. since your users are altering their sort preferences by clicking our column header links, they're not SUBMITting their pages with each click. because of this, you're not given an opportunity to trap the value of :REQUEST. you can get it after the fact, though, because we store it as an html db Preference value. the syntax to store the your users' last column sort preference into a local variable would be...
declare
l_pref varchar2(200) default null;
l_region_id number default 123456;
begin
l_pref := wwv_flow_preferences.get_preference (
p_preference => 'FSP'||wwv_flow.g_flow_id||
'_P'||wwv_flow.g_flow_step_id||'_R'||l_region_id||'_SORT');
end;
...so assuming you had a report region whose ID was 123456, the above code would trap the last sort preference for your current user's session. (you'd probably want to insert this value into your stored report table, so you can get to it later.) so now that you know the region_id and your user's last sort preference, you just have to put those values back into the right places in your URL to get things to work. as you know, the value for :REQUEST goes in the fourth slot in our f?p= URL syntax. then you throw in the extra "&fsp_region_id=123456" at the end of that URL (assuming your region's id was 123456). in your case, you're storing your full query in a table. you'd probably want to pass your report page some id to let it know which query to run off of. assuming your region id is 123456, your report page is 5, the id that your stored queries table needed for this user was 7, and your user lasted sorted by the third column of the query, this is the type of URL that you'd need to pass to the HTML DB engine...
http://htmldb.oracle.com/pls/otn/f?p=&APP_ID.:5:&SESSION.:fsp_sort_3:::P5_MY_STORED_QUERY_TABLE_ID:7&fsp_region_id=123456
...where &APP_ID. and &SESSION. are substituted appropriately for you by html db. i know this is a lot of info, so far, but there is one more twist to all this: it appears that the value stored as a preference reflects the opposite order of ascension as the one the user indicated. so if your user clicks the 3rd column header of your report to sort by that column, the REQUEST value passed to our engine would be fsp_sort_3. the value stored as a preference would be fsp_sort_3_desc. i know that's weird, but that's just how it goes. since we're hacking, here, we can't really complain ;-)
hope this helps,
raj