Full Report Browse

[DDP021]

Has anyone utilized the FULL REPORT BROWSE option?..How does it work?...I see there is an option under the FOLDER setup under the PERMISSIONS tab..Is that for each specific user or group?..Also, I see on the USER definition under to FOLDER PERMISSIONS tab there is a FULL REPORT BROWSE check box...Does this need to be checked also?....I can't find any documentation on how exactly this feature work?

[Greg Ira]

If your load gets broken up into mulitple documents, full report browse allows you to see all the documents in the original, all in one, document.  For example if you load a document with 12 statements and your indexing breaks on account # causing it to store it as 12 separate documents,  If you select one of those then click on "Full Report Browse" CMOD will present all 12 statements as one document.  We've found this handy for some of our users who have to do end of run summaries and such.
 Both the folder and user checkboxes do the same thing.  If you check off one, the other will show checked off.  It can be used for both specific users or for a group.

[DDP021]

Thanks Greg for the info...What FULL REPORT BROWSE  boxes need to be checked?..On both the FOLDER setup and USER ID setup?....We have a HUGE HUGE report with over 20 indexes....Users were looking to  be able to search the entire version for information...Currently the FIND option will only work in the index they are currently viewing..Just trying to determine was "flags" need turned on...

[Greg Ira]

It Doesn't matter which one you turn on.  I have a feeling they're both pointing to the same table as that when I check one off (ie in the User) the other shows as checked off(ie in the folder).

[DDP021]

Ok..Gotcha...We tried on this one SUPER large report...We searched on particular version..Then clicked on FULL REPORT BROWSE within the Document List..After it finally opened, when then attempted to do a search (FIND ALL) on a string across the entire version...It sat there spinning for a LONG time and then we eventually received a message indicating it wasn't responding then had to shut down...As indicated this is an extremely large report with over 20 indexes..That maybe the issue but we need to know for sure to relay it to the user that the function will not work because of the version size...

[pankaj.puranik]

Full Report Browse
Allows a user of the OnDemand client to select a document, retrieve that document, and view the entire report (load) to which the document belongs.

[Justin Derrick]

If you're having long wait times when searching HUGE documents, increase your large object size.  The default is 100, but 1000 is acceptable -- last time I checked, 1024 was the maximum for this value). 

Increasing the large object size reduces the round-trip calls to the server for the next object, improving performance dramatically -- and as a side effect, it may also improve compression, saving you disk space.

After you make this change, it will only take effect on NEW documents that get loaded, so you may continue to have performance issues with older documents.

[DDP021]

We'll give it a shot Justin!!!.It was set at 100..We'll see if the results are better the next time this report loads...Is there a guideline to when to we should increase the large object size?...

Also- another question...We recently upgraded to CMOD8.5...Ran into an issue where we were attempting to cleanup so older Application Groups/Applications...When we attempted to remove the Application Group via the 8.5 Admin client from one of our Admins PC, it immediately locked and went to a NOT RESPONDING...It then also seemed to stop ingestion via ARSLOAD...We had to have our systems area recycle ARSSOCKD in order to bring things back..Afterwards we could log back into everything and ingestion resumed...Ever hear of this kind of problem?..To us, we were just doing a basic ADMIN function...Thanks for all the help!!!!!!!...Take care....Dave

[Justin Derrick]

In terms of guidelines...  Well, when the report is tens of thousands of pages without a break, that's a good time to implement that change.  Most of the time you do it when users complain about long text-search times.

One customer had a user who would routinely search 70,000+ page reports for account numbers, and they said it took over 20 minutes -- and they used that 20 minutes to call and harass the helpdesk staff about how slow the server was.  I upped the large object size to 1000, and in my tests it took less than a minute to find the last account number in the document (a worst case scenario).  After we implemented the change in production, that person stopped calling -- that's how we measured the success of that particular change... 

-JD.

[DDP021]

Gotcha!....Just wanted to be sure making this change wouldn't adversely effect something else...We can't wait to test out this change after the next loading of this report..And I know exactly where you're coming from with the customer reaction!..No better gauge to let you know how things are going!!..As we know, a customer normally doesn't call just to tell you how good things are!!....BUT, when there's an issue...........;-)...

[DDP021]

Justin, I made the change to 1000 on the large object setting on the Application....I loaded last night with a new version....Let me state it took OVER 45 minutes just to load the current version..After it finally loaded the version I clicked on VIEW FULL REPORT box under Document List the screen went white and then I received an "Insufficient memory to perform this function" error...I've attached the error ...Any ideas?...I'm guessing this report is just TOO big??!??

[Justin Derrick]

Yow.  It looks that way.  Load times shouldn't be drastically affected though.  I know you're on 8.5.0.6, so you might be looking at the GSKit bug.

[DDP021]

This particular report was over 8 million bytes...Another report from this same application is over 21 million...Their were having issues attempting to do downloads via the Webi client so we setup them to be able to access the thick client via citrix...We had tested the VIEW FULL REPORT option using a smaller report with no issues...I see you indicated something about a GSKit bug?...Not sure what that is or if its something that can be corrected...Appreciate the help as always...