Currently I can see the that the retrieving and displaying of any search function is set to 40 records. Synchronization between the client and the server for scrolling through the result set is control by the appliction. I need to increase this size to increase our performance when we use the Print Merge function or the Import/Export Utility. I can see that when these functions are being used it is fetching 40 records at a time so I am assuming that this is the default for the client to control the scrolling through the record set using the UI screens. But it is choking us when we try to use the Print Merge Function or the Trimport Utility.
I'm pretty sure that there should be a registry key setting or something in a configuration file that can modify the default number of records to send back to the client from a search results.
This is really critical that I find out how to increase the throughput because we need to export large amounts of records out of our TRIM System to be imported into our New York State Statewide Information System. We at the New York State Education Department have come to depend on our TRIM system and if we can't provide the data to our Statewide Task Group in a timely manner than we could lose the ability to keep our TRIM system and we will have to migrate over to the new Statewide System which is using Accela.
So any suggestions on how to increase the speed of using these two export functions would be greatly appreciated.
There is no registry key involved with the chunking of data, at least not one that is published. There are ways to improve performance though. It's probably best that you reach out to HP or your business partner for assistance. A lot of it is environment, version, or usage related (which you may not want to publish here).
The version we are on is 7.1 and we are running Oracle in a Window environment. I'm new to this environment but I have worked on client/server systems like this a lot of times and I can't believe that they would of hard coded the fetching mechanism. I have a support ticket in on this issue but it seems like they are having a hard time finding out the answer to this simple architecture question. I'm very surprise that with the size of this organization (Over 400 licenses) and in order to help us not lose our ability to keep this system that there is no answer to this simple question. I have to find a solution quickly and I am not even sure if it could be done through the API. Because of time constraints I have to go this way for now but if anyone has programmed to the API do you know if you can set the size of the record set fetching. If you have any examples I would appreciate it.
ps. I don't know maybe 400 users is not that big of a deal within this environment. First time working with a Document Imaging and Workflow system. What is a typical size organization for this kind of tool?
Sounds like you need some support from a technical consultant. Unfortunately this is too big of a topic for the back and forth nature of this form. If you want some remote assistance on Friday I can help you then. Shoot me a message and we can arrange a time.
If you're including Date Due for Destruction in the Print Merge fields, that could be slowing things down considerably. There's a known issue with this calculated field when included in Print Merge. Not sure yet if that same issue affects exporting using TRIMPort as well.
Note: Any posts I make on this forum are my own personal opinion and (unless explicitly stated) do not constitute a formal commitment on behalf of HPE.
(Please state the version of CM you're using in all posts.
HPE Software Support Online (SSO): https://softwaresupport.hpe.com/
No I'm not using Date of Destruction. You can watch the fetching routines that they have programmed into their client/server model. They are using the standard 40 records because the UI (user) can only scroll one page of records at a time so they slow down the process of synchronizing the scrolling though the result set and avoid sending unnecessary records over the network. I'm pretty sure about that but I don't want to be limited by 40 records and right now they are telling me that there is no place on the client where you can increase this size.
This is the best solution I have received so far from their support line:
Basically the settings that you’re looking for in handle by the TRIM database, to be more specific, the store procedure called “ConstructManyRecords” and not the Windows registry.
Basically you can alter the Store Procedure and increase the size of records to be displayed by the grid, however this is not tested, not supported and we would not recommend doing this.
Now I guess I will look into the API and hopefully there will be a property that will allow me to increase the size of the result set but even better allow me to control it myself.