Hi Misi

Thanks for providing the 6.3 version. I've just ran it against 2 records
that had failed with version 7.0 and they both worked. 

I'm now running against a bigger batch (5k records) that had failed
before. Let's see it the good results keep coming! 

Unfortunately I couldn't find out why the records are failing with
version 7.0. Please let me know if you want me to send any log file or
data sample, just in case you want to dig deeper on this issue.

I will obviously keep you informed on the final result.

Once again, thanks very much for your assistance

Cheers
Rafael Bertolini
 
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky
Sent: 27 July 2010 16:47
To: arslist@ARSLIST.ORG
Subject: Re: Error using rrrchive

Hi,

My guess is that the caracters encoded might be the problem.

RRR|Chive leaves to the ARAPI to do the character conversion, but if the
target database does not support a specific character, you might get a
problem. I guess...

I also guess that in version 5.x of the AR System, character encodings
were not strictly enforced, and that bad characters could have ended up
in
the database. The bad codes could be something that got there on even
older versions of your system.

When you go via ARX-files, the character codes are rechecked, and
possibly
cleaned, before the import.

I will send you a private mail with the URL to the 6.3-version of
RRR|Chive, so you can test that as well.

        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.
Find these products, and many free tools and utilities, at
http://rrr.se.

> Hi Misi
>
> Yes, I could set ARAPILOGGING on the current version and it generated
> the log file, but as you expected, no really useful information was
> provided (just the failed ARMergeEntry with no description on why it
> failed).
>
> The faulty records always fail. I can use "qual" to try to migrate
only
> one faulty record and it always fails with the same message. (ARERR
91)
>
> I then exported the faulty record and imported it into the new server
> and I noticed something strange: on the original server I have some
> Japanese (I think) characters and they were imported as "?"
characters.
> (I can see the Japanese characters in the ARX file).
>
> Anyway, I can see records that were migrated successfully and have
> Japanese characters (not as many as this one though) and I can also
see
> records that failed to migrate and don't seem to have any Japanese
> characters, so not sure it's related to the problem.
>
> If possible, I'd like to test with the 6.3 version, just to try all
the
> possibilities.
>
> I'm really sorry to keep bugging you with this. Thanks very much for
all
> your assistance.
>
> Regards,
> Rafael Bertolini
>
> Consultant
> Fusion Business Solutions (UK) Ltd
> Tel: +44 208 8146177
> Mob: +44 7500 441522
> www.fusion.co.uk
>
> Fusion is the largest consultancy in Europe that focuses exclusively
on
> BMC Software solutions
>
> -----Original Message-----
> From: Action Request System discussion list(ARSList)
> [mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky
> Sent: 27 July 2010 12:17
> To: arslist@ARSLIST.ORG
> Subject: Re: Error using rrrchive
>
> Hi,
>
> ARAPILOGGING exists for old versions as well, but may not be well
> documented. Follow the information for 7.5 ARAPILOGGING.
>
> I do not think that you will get much out of that though, as the
failing
> call is ARMergeEntry, and we get the error message...
>
> The only thing I can think of is incompatibility issues between your
5.x
> server and the 7.0 API, and that for the ARGetEntry for some reason
give
> us a corrupt structure.
>
> Does the exact same records fail each time?
>
> Have you tried to export one of the problematic records to an ARX-file
> (ARUser) and the importing it with ARImport?
>
> I may be able to supply a 6.3-API version of RRR|Chive that may work
> differently. Any API should be working 2 versions backwards and 2
> versions
> forward, at least.
>
>         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.
> Find these products, and many free tools and utilities, at
> http://rrr.se.
>
>> HI Misi
>>
>> Thanks for your reply.
>>
>> I took a look at ARERR91 description and then checked the handlers on
> my
>> windows server and it seems to be ok.
>>
>> Answering your questions, one server is version 5 and the other 7.1.
> I'm
>> migrating data from an archive form with no workflow related to it.
>>
>> In the server error log file there's no error at all. I also enabled
> the
>> API log on the server and I can see the ARGetEntry and a ARMergeEntry
>> calls as you explained, but again, no error at all (I guess the
failed
>> records are failing before these two calls).
>>
>> Taking a look at the troubleshooting guide, I see API 7.5 has a
>> client-side ARAPILOGGING environment variable that we can be set to
>> generate client-side logs. However, I suspect the rrrchive version I
>> have is running with API 7.0 (arapi70.dll) and checking this version
>> troubleshooting guide, there's no mention to this functionality. Just
>> wondering if there's a new rrrchive that uses API 75?
>>
>> Again, many thanks for your assistance. I'll continue to try to find
>> different ways to generate different logs to see if any of them will
>> help me to find the problem.
>>
>> Regards,
>>
>> Rafael Bertolini
>>
>> Consultant
>> Fusion Business Solutions (UK) Ltd
>> Tel: +44 208 8146177
>> Mob: +44 7500 441522
>> www.fusion.co.uk
>>
>> Fusion is the largest consultancy in Europe that focuses exclusively
> on
>> BMC Software solutions
>> -----Original Message-----
>> From: Action Request System discussion list(ARSList)
>> [mailto:arsl...@arslist.org] On Behalf Of Misi Mladoniczky
>> Sent: 26 July 2010 14:14
>> To: arslist@ARSLIST.ORG
>> Subject: Re: Error using rrrchive
>>
>> Hi,
>>
>> This is what the error message means: http://rrr.se/cgi/arerrr?n=91
>>
>> The debug-level does not improve information, as this is a
> BMC-generated
>> error message. Something goes wrong in the RPC-call to the server,
all
>> encapsulated inside the AR-API supplied by BMC.
>>
>> In general, rrrchive just performs an ARGetEntry and a ARMergeEntry
> call
>> to the server, not modifying the actual data. The problem has to be
>> found
>> somewhere on the target-server.
>>
>> Which version do the two servers have?
>>
>> Do you use the target_disable_merge_fltr=YES? If not, there may be
>> merge-filters that cause the problem.
>>
>> Do you have anything in the server-error-log on the target server?
Any
>> threads crashing?
>>
>> I would try to increase logging on the Remedy-server to get more
info.
>>
>> What do you other people have to say about ARERR 91?
>>
>> The verifydata and verifyattachents is something that happens after
> the
>> ARMergeEntry to the target server. In other words after you get the
>> ARERR
>> 91. These options are useful only if you do not rely on the AR-API to
>> give
>> an error message if things fail. It rereads the target record created
>> and
>> compares it to the original.
>>
>>         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.
>> Find these products, and many free tools and utilities, at
>> http://rrr.se.
>>
>>> Hi
>>>
>>>
>>>
>>> I'm using rrrchive to migrate some data between two servers. In
>> general,
>>> it's working just fine but some records (around 5%) fail to migrate
>> with
>>> the following log:
>>>
>>>
>>>
>>> rrrchive: 2010-07-22 11:55:14, type=ARS, level=ERROR,
>> file=rrrchive.cpp,
>>> line=417
>>>
>>> ARMergeEntry(server=<servername>, form=<form name>,
>>> entry=A00000000000002)
>>>
>>>   API CALL SEVERITY: AR_RETURN_ERROR, failure, status contains
> details
>>>
>>>   ARStatusList: contains 1 messages
>>>
>>>   Number: ARERR 91
>>>
>>>   Message: Cannot open catalog; Message number = 91
>>>
>>>   Append: RPC: Can't encode arguments
>>>
>>>
>>>
>>> I've tried to increase the log level to DEBUG but there's no
>> additional
>>> log being generated. I've also tried using "verifydata" and
>>> "verifyattachments", all with the same result. I can see some
records
>>> with attachment were migrated fine (and some records without
>> attachment
>>> failed) so I don't think it's "attachment related".
>>>
>>>
>>>
>>> Any ideas on how to get a more detailed log or what could be causing
>>> this error?
>>>
>>>
>>>
>>> Cheers
>>>
>>> Rafael
>>>
>>>
>>>
>>
>
________________________________________________________________________
>> _______
>>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>>> attend wwrug10 www.wwrug.com 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
>> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>>
>>
>
________________________________________________________________________
> _______
>> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
>> attend wwrug10 www.wwrug.com 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
> attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"
>
>
________________________________________________________________________
_______
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> attend wwrug10 www.wwrug.com 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
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
attend wwrug10 www.wwrug.com ARSlist: "Where the Answers Are"

Reply via email to