Right you are. (Just played around with driver). Clearly some doc is missing from the API guide. Very different behaviour than ARGetListEntry for the same argument.
Cheers Ben -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky Sent: February-07-11 18:08 To: arslist@ARSLIST.ORG Subject: Re: General Q on 7.6.3 API ARGetListEntryWithFields char 0 (& diary) field restriction removal; comment on ARSetGetEntry() Hi, If you specify NULL for the field list, you get no error against the 6.3 server from the 7.6 driver. If you do not specify any fields in ARGetListEntryWithFields, only the form specified result-list-fields are returned. This is true for all server versions I would imagine. 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 trying this out with the driver for me. The change may > have been introduced in 7.5. There would be (and isn't) and .h change > as all arguments are the same and behaviour isn't documented in ARS .h files. > Clearly a bit of a doc bug in 7.6.3 then. > > I note that the error you received is 241 which says " char fields > > 256 bytes | diary fields | char 0 fields". I sure hope that ain't > true about the > 256! > > I generally set NULL for the field list meaning give me everything. I > expect that in that case, you should get no error but no value for the > char 0 field. This would be "compatible" after all. > > Cheers > Ben > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky > Sent: February-07-11 17:22 > To: arslist@ARSLIST.ORG > Subject: Re: General Q on 7.6.3 API ARGetListEntryWithFields char 0 (& > diary) field restriction removal; comment on ARSetGetEntry() > > 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:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >> Sent: February-07-11 14:57 >> To: arslist@ARSLIST.ORG >> 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:arslist@ARSLIST.ORG] On Behalf Of Misi Mladoniczky >>> Sent: February-07-11 11:03 >>> To: arslist@ARSLIST.ORG >>> 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:ben.cher...@softwaretoolhouse.com> >>>> ben.cher...@softwaretoolhouse.com >>>> 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" > > ______________________________________________________________________ > _________ 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"
