Hi,
I think we are complicating things here.
If an object has changed name, just handle is as one deleted and one added
object. It could still be an incremental thing, meaning that we do not
update all other forms or objects.
I also think that going in and updating OBJ_PROPs through ARInside would
make it more dangerous to use. If it only reads things it can do no great
harm.
Best Regards - Misi, RRR AB, http://www.rrr.se
Products from RRR Scandinavia:
* RRR|License - Not enough Remedy licenses? Save money by optimizing.
* RRR|Log - Performance issues or elusive bugs? Analyze your Remedy logs.
* RRR|Translator - Manage and automate your language translations.
Find these products, and many free tools and utilities, at http://rrr.se.
> LJ,
>
> Which actually brings to the surface the question of: "What happens
> when an object name changes?". My guess is that the object would look
> like a "new object" and there really would be no good way to tie it
> back to the previously used "internal id".
>
> Now if you were to use the "AR_OPROP_GUID" value (and have it set in
> all of your objects) then you would have a shot at some of these
> approaches. Or you could add your own tag too...
>
> Ref: C-APIGuide-630.pdf pg 75
> "
> Note: Object property tags with a value of AR_OPROP_LAST_RESERVED or
> below are reserved. The API programmer might define any tag with a
> value above AR_OPROP_LAST_RESERVED.
> "
>
> Unfortunately there is even a risk at the field level of the "Field ID
> changing". (Much harder to do , but there have been tools to achieve
> that kind of task before.) So unless the "AR_OPROP_GUID" value is down
> to each field ( I do not think it exists at that level so how much of
> this can be done my be limited or have some consequences due to the
> level at which the GUID exist.) then you would likely still have
> issues.
>
>
> Now if the ARInside tool would actually set any missing
> "AR_OPROP_GUID" values for every object then you would have a good
> shot at this. (Though I think it could also be changed if you tried
> hard enough.) But the cost of updating every object the first time the
> tool is run against a production server would likely be less than
> ideal for most users/companies.
>
> --
> Carey Matthew Black
> BMC Remedy AR System Skilled Professional (RSP)
> ARS = Action Request System(Remedy)
>
> Love, then teach
> Solution = People + Process + Tools
> Fast, Accurate, Cheap.... Pick two.
>
>
>
> On Fri, Oct 9, 2009 at 10:35 AM, LJ Longwing <lj.longw...@gmail.com>
> wrote:
>> Hey Misi,
>> Before I got into the code, I wondered the exact same thing,
>> unfortunately
>> the ability to do that is limited with the current design. As ARInside
>> grabs objects from the server (in the order it grabs them, which can be
>> different each time), it assigns an 'internal id' to the object, and
>> that
>> internal id is what it uses to process objects. To do a 'difference'
>> run
>> you would need to keep a db of some sort around of what your object id's
>> were for your last run, and then assign them back to the same id's on
>> the
>> next run. It's definitely possible, but is a rewrite of a significant
>> part
>> of the code I think....that's not to say it won't be done, just that it
>> won't be 'now'...:)....if you want, please feel free to log it as an
>> enhancement request though :)
>>
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky
>> Sent: Friday, October 09, 2009 1:15 AM
>> To: arslist@ARSLIST.ORG
>> Subject: Re: ARInside 3.0 Beta
>>
>> Hi,
>>
>> In theory, it should be possible to leverege the modify-time of the
>> server
>> objects to do an incremental update of the previous run.
>>
>> All ARGetList*()-functions has a last-modify-date parameter, to allow
>> retrieval of changed objects.
>>
>> You will also need to remove any objects that has been deleted.
>>
>> This would be a really good improvement on performance.
>>
>> I have not looked at the code (yet...) though.
>>
>> Best Regards - Misi, RRR AB, http://www.rrr.se
>>
>> Products from RRR Scandinavia:
>> * RRR|License - Not enough Remedy licenses? Save money by optimizing.
>> * RRR|Log - Performance issues or elusive bugs? Analyze your Remedy
>> logs.
>> * RRR|Translator - Manage and automate your language translations.
>> Find these products, and many free tools and utilities, at
>> http://rrr.se.
>>
>>> We ran it against a 7.1 and 7.5 server with Help Desk, SLA 6 and a ton
>>> of custom apps with no issue. I didn't notice any change in
>>> performance.
>>> The
>>> batch file we use to kick it off logs the start and stop time. It
>>> still averaged about 4.75 hours for both servers.
>>>
>>> It is much cleaner now with the default of not being verbose and the
>>> web service stuff looks great!
>>>
>>> Thanks for keeping this alive.
>>>
>>> Jason
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
>
> --
> This message was scanned by ESVA and is believed to be clean.
>
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
Platinum Sponsor:rmisoluti...@verizon.net ARSlist: "Where the Answers Are"
