I have developed a utility posted at: http://communities.bmc.com/communities/docs/DOC-11866 The Fast-Export utility deal carefully with Diary fields and has backward and upward computability, the aim of the utility when developed is to avoid using ARGETLISTEntry and deployed a process based on the concept to repeatedly read the schema rows in a sequential order. The logic initiated to read the schema in forward or backward sequence of order. Users for backward or forward sequence can initiate the START-Read, to identify the starting point of the browse, and terminated with the END-Read. Try this utility and see if it will achieve your objectives.
Overview: Fast-Export is a migration utility that copy a data of a schema or a list of schemas from server to server for an identical schemas (schema-to-schema) or as a normal export utility (schema-to-file) send output to (.arx/.csv) file that can be imported by Remedy Import. Fast-Export designed based on the concept to repeatedly read the schema rows in a sequential order. The logic initiated to read the schema in forward or backward sequence of order. Users for backward or forward sequence can initiate the START-Read, to identify the starting point of the browse, and terminated with the END-Read. Ease-of-use facilitated with .NET window client which was developed to help users to access through a GUI, it was developed using the feature of .NET/C# so that to be executed as Windows (future Web-Based) and valid to access BMC-Remedy releases AR3-7.: To use it: 1) Unzip the zipped file, 2) It generate a folder call FastExport 3) Run: FastDotNet.exe -----Original Message----- From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys Sent: Monday, February 07, 2011 5:41 PM To: arslist@ARSLIST.ORG Subject: Re: General Q on 7.6.3 API ARGetListEntryWithFields char 0 (& diary) field restriction removal; comment on ARSetGetEntry() 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"
