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™ 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
