All,
Looking for a sanity check on a particular piece of
java api code
EntryListInfo[]
entryInfo =
EntryFactory.findEntryListInfos(
context, listCriteria, criteria, false, nMatches );
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
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 Skeptic™ 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™ technology powered by MessageLabs. For more information on Verizon Managed Email Content Service, visit http://www.verizonbusiness.com.
______________________________________________________________________
__20060125_______________________This posting was submitted with HTML in it___
