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"