Hi,
I tried it quickly with the driver-program:
LOG
INIT
GLEWF
My 6.3 server returned the usual error message ARERR 241.
The 7.5 and 7.6 seems returns the correct data.
I checked the SQL and API on 7.5, and it performs a single API/SQL-call
including the big field without complaining.
Apparently this was implemented on the server side earlier than 7.6 but
later than 6.3.
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,
>
> Thanks for your comments.
>
> What I really want is an answer to the backward compatibility processing
> of the ARGetListEntryWithFields() call - which is missing from the
> documentation. This will enable me to decide to use it or not with this
> release 7.6.3. So, if someone connected with that API knows the answer,
> please post it. If someone has used this API, attempted to retrieve char
> 0 fields on an older server and either succeeded or failed and if
> succeeded, knows - through API and SQL logging - how the API implemented
> the getting of the char 0 values, I would appreciate hearing from them.
>
> I expect that in all probability the API will not return char 0 fields.
> This is "compatible" I expect. But would like to know none-the-less
> because the documentation is missing this backward compatibility
> explanation which it has for other f() changes.
>
> Why not turn on API logging? I always run my servers with full logging.
> I ask the question because I don't want to waste time with code changes
> and building test forms and data etc until I know what the scoop is.
>
> I regularly retrieve way more than 1000 records. When dealing with
> millions or hundreds of millions 100 doesn't seem like much does it? And
> on old servers to boot. Char 0 fields rarely contain anything over a few
> k or at most a single Mb. They are generally quite small.
>
> You didn't understand my Administrator comment. One cannot call
> ARGetListSQL() without being an Administrator. The API f() is restricted
> to Administrator users.
>
> The problem with performance is (almost) never what happens on the server
> but how many IP requests you need to make on that server. Hence the
> evolution of the API to reduce that packet turnaround.
>
> Cheers
> Ben
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:[email protected]] On Behalf Of Misi Mladoniczky
> Sent: February-07-11 14:57
> To: [email protected]
> Subject: Re: General Q on 7.6.3 API ARGetListEntryWithFields char 0 (&
> diary) field restriction removal; comment on ARSetGetEntry()
>
> 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"
>
> _______________________________________________________________________________
> 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"
