Hi, To force retrieval of all matching entries, there is a "special" maxRetrieve value applicable for query API calls (GetListEntryXXX/GetListSQL etc):
#define AR_RETRIEVE_ALL_ENTRIES 999999999 /* retrieve all entries even if there is a limit on the number of entries that the server will return */ You can give this number as the max retrieve and the server will return *all* matches irrespective of the actual predefined server side limit. I believe this works only for Admin privilege users and of course lot of thought be given to performance considerations before using this - basically when a really valid use case exists OR a very infrequent operation by the client. For example, Admin Tool's server window display is a good use case to be using this flag. Where as User Tool's result list or table field refresh code -- should not be using this flag. So hopefully this value is used sparingly on an as needed basis and with backing of well thought out reasons for using it. Lot more generic (but more code to write) way to approach this issue is to retrieve the data in chunks by repeatedly calling GetListXXX function by specifying firstRetrieve=0,maxRetrieve=1000; firstRetrieve=1001,maxRetrieve=2000; firstRetrieve=2001,maxRetrieve=3000; and so on. The EntryBlock API Misi mentioned is just a wrapper on GetListWithFields C API call, but allows for a "callback" mechanism to retrieve data in blocks rather than all-at-once. This method is a client side optimization for data marshalling between Java and native code in the client side. It does not deal with the server side chunked query responses (which is controlled by first/maxRetrieve parameters in the GetListEntryXXX API calls). Regards Appajee -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:[EMAIL PROTECTED] On Behalf Of Misi Mladoniczky Sent: Wednesday, September 13, 2006 9:01 AM To: [email protected] Subject: Re: Java API max entries Hi Eric, I do not know if the same restrictions apply to the new API-call ARGetListEntryBlocks() and ARGetEntryBlock(). It could be worth a try. I do not know how these are implemented in the Java API. Another solution could be to issue multiple queries. Even though this results in a table-scan, an easy way to split a query is to issu, i.e. 10 queries with the following criteria: ('1' LIKE "%0") ('1' LIKE "%1") ('1' LIKE "%2") ... ('1' LIKE "%9") Best Regards - Misi, RRR AB, http://www.rrr.se > All, > > Looking for a sanity check on a particular piece of java api code > > EntryListInfo[] entryInfo = EntryFactory.findEntryListInfos( > context, listCriteria, criteria, false, nMatches ); > > If I use a qual of 1=1, nMatches returns a count of all entries in the > form > (i.e. 29993). > When using entryInfo.length, returns a value of 10k, which is max entries > set by server. > > Other than writing a loop to re-query after handling the first 10k records > or turning off Max Entries, is there any way to bypass the server max > records limit? > Any advice would be appreciated. > > Ars 6.3 and Ars7.0 > Using 7.x api > > > Eric Roys > Sr. Software Engineer > Verizon Business > Email: [EMAIL PROTECTED] > > CONFIDENTIALITY: The information contained in this message and any > attachment may be proprietary, confidential, and privileged or subject to > the work product doctrine and thus protected from disclosure. If the > reader > of this message is not the intended recipient, or an employee or agent > responsible for delivering this message to the intended recipient, you are > hereby notified that any dissemination, distribution or copying of this > communication is strictly prohibited. If you have received this > communication in error, please notify me immediately by replying to this > message and deleting it and all copies and backups thereof. Thank you. > > > > _____ > > From: Action Request System discussion list(ARSList) > [mailto:[EMAIL PROTECTED] On Behalf Of Jason Miller > Sent: Wednesday, September 06, 2006 1:26 PM > To: [email protected] > Subject: Re: Question: Disable ODBC > > > ** Tyrone, absolutely you can restrict everybody except admins. That is > the > beauty of it, you have the flexibility of any query that can be run in a > filter Run If. > > Firing on every get entry is definitely something to take into > consideration > and was one of my concerns. I figured since it is not a query to the db it > wasn't too much of a performance hit for my situation (it is still an API > call to the server each time you view a record but there are going to be > other various API calls anyways when you view a record). Plus I didn't > know > about the Disable-Client-Operations option. > > Thanks for the "Disable-Client-Operation". This looks like an awesome > feature that I will play with. You could actually get to the user level by > creating a computed group and specify login names (or a mix of login names > and groups). Depending on the size of your system and the way you have > your > groups setup it could become a maintenance burden to make sure all new > users > are properly restricted. > > I guess this is were the get entry filter option has a bit more > flexibility > because you can disable everybody as a baseline and enable ODBC operations > for a group with a NOT statement (i.e. NOT $GROUPS$ LIKE "%" + > "Administrator" + "%" versus having to disable each group individually > using > the config file. But even then you could have a computed group with all > groups except the Admin group to use with the Disable-Client-Operation. > Many > ways to do it (I love ARS). > > Jason > > > On 9/6/06, Carey Matthew Black <[EMAIL PROTECTED]> wrote: > > All, > > ConfigGuide-630.pdf Page: 287: > > " > Disable-Client-Operation: <tag_number_to_disable> [[<start_time>]- > [<stop_time>]] [<group_ID_list>] > > Restricts time-consuming operations (such as reporting) during busy times, > improving the overall performance. This option can be set to certain times > the day. It can also exclude users of specific groups so that they are not > blocked from performing the specified operation. For example, you can > allow only the administrator to perform reporting during busy hours. > " > > So ... I think the config file option is the best bet. It would allow > any specified groups to be _excluded_ from the restriction. > > Jason's Get Entry filter option does go to one level more granular (to > the user not a group) and has the added performance expense of being > evaluated for every data row returned from the form. (Even for the > users listed in the Run If.) > > I wonder if the config option will (or was) similarly expanded like > the Assignee Group values were but BMC failed to document that > feature? (Maybe you can be user specific in the config file? if not, > then it would be a good REF idea IMHO.) > > -- > Carey Matthew Black > Remedy Skilled Professional (RSP) > ARS = Action Request System(Remedy) > > Love, then teach > Solution = People + Process + Tools > Fast, Accurate, Cheap.... Pick two. > > ________________________________________________________________________ ____ > ___ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org > > > > __20060125_______________________This posting was submitted with HTML in > it___ > ______________________________________________________________________ > This e-mail has been scanned by Verizon Managed Email Content Service, > using > SkepticT technology powered by MessageLabs. For more information on > Verizon > Managed Email Content Service, visit http://www.verizonbusiness.com. > ______________________________________________________________________ > > > > ______________________________________________________________________ > This e-mail has been scanned by Verizon Managed Email Content Service, > using Skeptic(tm) technology powered by MessageLabs. For more information on > Verizon Managed Email Content Service, visit > http://www.verizonbusiness.com. > ______________________________________________________________________ > > ________________________________________________________________________ _______ > UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org ________________________________________________________________________ _______ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
