Hi,
Why not turn on API-logging on the server to see what happens?
I don't want to argue, but retrieving 100 record a time as compared to
1000 would make no significant difference in time. The difference is that
a ARGetList* instead of an ARGetMultipleEntries, performs a single
SELECT-statement for everything, instead of one SELECT-statement per
record (albeit fast ones).
As for permissions, I guess that ARGetListSQL is fine if your program is
used by Administrators only. You will also have to convert the data into
appropriate data types. And as you stated may miss something
Get-Entry-Filters is supposed to supply.
As for the last caveat, it may actually be desirable, if you want to
extract data as represented in the database, as opposed to have it changed
by a Get-Entry-Filter.
>From a data synchronisation perspective, it would actually be very nice to
be able to suppress Delete-Filters, Get-Entry-Filters as well as
Audit-/Archive-Form data manipulation restrictions... At least for
Administrator users.
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
Find these products, and many free tools and utilities, at http://rrr.se.
> Hi Misi,
>
>>>> "We are talking about new API-functions against old servers only,
>>>> right?" Absolutely.
>
> I am using the ARGetMultipleEntries (which has no field restriction) but
> is limited to 100 records - a very very small amount! The 1000 is just
> an example. So, I must think about performance.
>
> ARGetListSQL bypasses the permissions model: yes, indeed, as I explained.
> It also required Administrator in and of itself, so is generally not a
> permissions issue. It may be a Get filter issue in extremely rare cases.
>
> The question is what does the 7.6.3 API do with the char 0 fields? If
> anything at all.
>
> I gather then that you haven't used it because of these restrictions to
> date?
>
> Thanks
> Ben
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Misi Mladoniczky
> Sent: February-07-11 11:03
> To: [email protected]
> Subject: Re: General Q on 7.6.3 API ARGetListEntryWithFields char 0 (&
> diary) field restriction removal; comment on ARSetGetEntry()
>
> Hi,
>
> We are talking about new API-functions against old servers only, right?
>
> If I implemented this, I would do it the easy way, and not think too much
> about the performance, as one would expect the server version to keep up.
>
> ARGetListSQL would be out, as it bypasses the permission model.
>
> I would do 10 ARGetMultipleEntries-calls to get the 1000 records. The
> additional API-calls would have little impact compared to the amount of
> data retrieved for unlimited-length (0) fields.
>
> Best Regards - Misi, RRR AB, http://www.rrr.se
>
> Products from RRR Scandinavia (Best R.O.I. Award at WWRUG10):
> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
> Find these products, and many free tools and utilities, at http://rrr.se.
>
>> Hi Folks,
>>
>>
>>
>> The API 7.6.3 removes the restriction of char 0 (& Diary) fields from
>> ARGetListEntryWithFields from its doc (it's about time!) but that same
>> doc does not indicate what happens when that API is used against an
>> older server.
>>
>>
>>
>> What can happen is:
>>
>> 1) The restriction is abided by, that is char 0 fields are not
>> returned in the arrays of field values
>>
>> 2) The API issues separate calls to return these values so that these
>> fields are returned.
>>
>>
>>
>> If (2) what types of calls and what is the performance impact? Ie if
>> there are 1000 results, are the an additional 1000 ARGetEntry calls
>> made?
>>
>>
>>
>> If (1) then I wonder further,
>>
>> If a single call to ARGetListSQL get those fields for the set of
>> returned records would be a reasonable thing to do (to have a total of
>> 2 server calls for 1000 records) (and with a constructed where
>> clause).
>>
>>
>>
>> The only issue would be that Administrator is required (almost always
>> used
>> anyhow) and that Get filters change could these fields values
>> (unlikely but possible).
>>
>>
>>
>> I note that the documentation for the new ARSetGetEntry() includes a
>> description of what happens on older servers. If I had my
>> preferences, that SetGet would also handle Creates and Merges as I
>> need to do a SetGet in those cases as well. So, SetGet is only a
>> limited performance gain for me.
>>
>>
>>
>> Thanks
>>
>> Ben Chernys
>>
>> Senior Software Architect
>> Software Tool House Inc.
>>
>> Canada / Deutschland / Germany
>> Mobile: +49 171 380 2329 GMT + 1 + [ DST ]
>> Email: <mailto:[email protected]>
>> [email protected]
>> Web: <http://www.softwaretoolhouse.com/>
>> www.softwaretoolhouse.com
>>
>> Check out Software Tool House's free Diary Editor.
>>
>> Meta-Update, our premium ARS Data tool, lets you automate your
>> imports, migrations, in no time at all, without programming, without
>> staging forms, without merge workflow.
>> <http://www.softwaretoolhouse.com/> http://www.softwaretoolhouse.com/
>>
>>
>>
>>
>> ______________________________________________________________________
>> _________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11
> www.wwrug.com ARSList: "Where the Answers Are"
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
