RE: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

[Ben Chernys]

Ha.  You may be right there.  Software numbering is always an arcane endeavour. 


/Ben

 

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of LJ LongWing
Sent: January-31-18 9:49 AM
To: ARSList <arslist@arslist.org>
Subject: Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" 
with workaround; BMC Bug raised; fix ~ 9.5

 

my hesitance regarding '9.5' specifically is surrounding that 9.5 was the 
planned version of the next version of Remedy which included Innovation 
Suitea bit over a year ago Innovation Suite was moved off into it's own 
product suite and is no longer planned to be part of Remedybecause of that 
I don't expect BMC to 'reuse' that version number at any point in the 
future...if they continue with the current numbering scheme, I expect them to 
skip 9.5 entirely and go with a 9.6 or 10.0 or something like thatbut I 
personally don't think they will use 9.5all of these statements are my own 
personal thoughts on the subject and not 'inside knowledge' of any sort :)

 

On Wed, Jan 31, 2018 at 8:26 AM, Ben Chernys <ben.cher...@softwaretoolhouse.com 
<mailto:ben.cher...@softwaretoolhouse.com> > wrote:

Hi LJ,

 

I am getting this from my client – although I was involved in the support 
ticket.  So, I didn’t hear it from the horse’s mouth.  I was told “around 9.5”.

 

It doesn’t really matter when it is fixed.  The OOTB ITSM apps generally do not 
have umlauts in the “Query Fields” defined for the forms.  Meta-Update works 
around the problem by supplying its own QueryFields list.  This bug is rare.

 

I have two clients with this problem.  One modified HPD:Help Desk’s Query 
Fields list to have fields whose values include umlauts.  The other has their 
own app.

 

In fact, it does make sense.  I have heard statements like this from many many 
software companies and I myself have made statements like this.  Remedy is a 
big piece of software and all fixes need to be tracked and scheduled.  It just 
indicates that this is currently planned to be fixed in that release.  Once it 
is assigned and investigated, times may change.

 

Cheers

Ben

 

From: ARSList [mailto:arslist-boun...@arslist.org 
<mailto:arslist-boun...@arslist.org> ] On Behalf Of LJ LongWing
Sent: January-31-18 8:08 AM
To: ARSList <arslist@arslist.org <mailto:arslist@arslist.org> >
Subject: Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" 
with workaround; BMC Bug raised; fix ~ 9.5

 

Ben,

Your statement regarding being fixed around '9.5' doesn't make any sense to 
medid whoever you talked to SAY 9.5 or did they say 'next release', or more 
likely 'future version'?

 

On Wed, Jan 31, 2018 at 7:59 AM, Ben Chernys <ben.cher...@softwaretoolhouse.com 
<mailto:ben.cher...@softwaretoolhouse.com> > wrote:

FYI

 

BMC has raised this as a bug and is expecting to fix it around 9.5.

 

Cheers

Ben

 

From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com 
<mailto:ben.cher...@softwaretoolhouse.com> ] 
Sent: May-29-17 7:57 AM
To: 'arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG> ' <arslist@ARSLIST.ORG 
<mailto:arslist@ARSLIST.ORG> >
Subject: RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using 
UTF-8 on their DB on anything > 7.6.04? - "solved" workaround

 

Hi All,

 

I have heard back from the customer.  The work-around does indeed work around 
the problem.  It seems the bug is related only to building the short 
description string for an ARGetListEntry response.  The server comes back to 
the client and the client responds that it can’t decode the result (ARERR 992) 
if and only if the any of the result’s descriptions have umlauts.  

 

Meta-Update uses that string in its messaging:  Qry 1 of x: default short 
description (get fields) from the record.  Simple solution for those using the 
API is to override the default short description generation with a single field 
known to not contain any special characters such as umlauts (such as ‘1’).

 

This bug seems to have been introduced in 9.1 or at least this customer did not 
experience it before the upgrade to 9.1.0 – from which version I know not – but 
running on HP-UX. :)  I haven’t tested in on my servers (9.1.02, 8.1, …) to see 
when it was introduced and the fact that I run UTF-8 may affect the test.

 

Cheers

Ben

www.softwaretoolhouse.com <http://www.softwaretoolhouse.com> 

 

 

From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] 
Sent: May-25-17 9:10 AM
To: 'arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG> ' <arslist@ARSLIST.ORG 
<mailto:arslist@ARSLIST.ORG> >
Subject: RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using 
UTF-8 on their DB on anything > 7.6.04?

 

Hi Fred,

 

Thanks for your reply.

 

I have no access at all to the client Windows machine or the Linux server – not 
even WebEx.  As for the DB, I expect 

Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

[LJ LongWing]

my hesitance regarding '9.5' specifically is surrounding that 9.5 was the
planned version of the next version of Remedy which included Innovation
Suitea bit over a year ago Innovation Suite was moved off into it's own
product suite and is no longer planned to be part of Remedybecause of
that I don't expect BMC to 'reuse' that version number at any point in the
future...if they continue with the current numbering scheme, I expect them
to skip 9.5 entirely and go with a 9.6 or 10.0 or something like
thatbut I personally don't think they will use 9.5all of these
statements are my own personal thoughts on the subject and not 'inside
knowledge' of any sort :)

On Wed, Jan 31, 2018 at 8:26 AM, Ben Chernys <
ben.cher...@softwaretoolhouse.com> wrote:

> Hi LJ,
>
>
>
> I am getting this from my client – although I was involved in the support
> ticket.  So, I didn’t hear it from the horse’s mouth.  I was told “around
> 9.5”.
>
>
>
> It doesn’t really matter when it is fixed.  The OOTB ITSM apps generally
> do not have umlauts in the “Query Fields” defined for the forms.
> Meta-Update works around the problem by supplying its own QueryFields
> list.  This bug is rare.
>
>
>
> I have two clients with this problem.  One modified HPD:Help Desk’s Query
> Fields list to have fields whose values include umlauts.  The other has
> their own app.
>
>
>
> In fact, it does make sense.  I have heard statements like this from many
> many software companies and I myself have made statements like this.
> Remedy is a big piece of software and all fixes need to be tracked and
> scheduled.  It just indicates that this is currently planned to be fixed in
> that release.  Once it is assigned and investigated, times may change.
>
>
>
> Cheers
>
> Ben
>
>
>
> *From:* ARSList [mailto:arslist-boun...@arslist.org] *On Behalf Of *LJ
> LongWing
> *Sent:* January-31-18 8:08 AM
> *To:* ARSList <arslist@arslist.org>
> *Subject:* Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; -
> "solved" with workaround; BMC Bug raised; fix ~ 9.5
>
>
>
> Ben,
>
> Your statement regarding being fixed around '9.5' doesn't make any sense
> to medid whoever you talked to SAY 9.5 or did they say 'next release',
> or more likely 'future version'?
>
>
>
> On Wed, Jan 31, 2018 at 7:59 AM, Ben Chernys <Ben.Chernys@
> softwaretoolhouse.com> wrote:
>
> FYI
>
>
>
> BMC has raised this as a bug and is expecting to fix it around 9.5.
>
>
>
> Cheers
>
> Ben
>
>
>
> *From:* Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com]
> *Sent:* May-29-17 7:57 AM
> *To:* 'arslist@ARSLIST.ORG' <arslist@ARSLIST.ORG>
> *Subject:* RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT
> using UTF-8 on their DB on anything > 7.6.04? - "solved" workaround
>
>
>
> Hi All,
>
>
>
> I have heard back from the customer.  The work-around does indeed work
> around the problem.  It seems the bug is related only to building the short
> description string for an ARGetListEntry response.  The server comes back
> to the client and the client responds that it can’t decode the result
> (ARERR 992) if and only if the any of the result’s descriptions have
> umlauts.
>
>
>
> Meta-Update uses that string in its messaging:  Qry 1 of x: default short
> description (get fields) from the record.  Simple solution for those using
> the API is to override the default short description generation with a
> single field known to not contain any special characters such as umlauts
> (such as ‘1’).
>
>
>
> This bug seems to have been introduced in 9.1 or at least this customer
> did not experience it before the upgrade to 9.1.0 – from which version I
> know not – but running on HP-UX. :)  I haven’t tested in on my servers
> (9.1.02, 8.1, …) to see when it was introduced and the fact that I run
> UTF-8 may affect the test.
>
>
>
> Cheers
>
> Ben
>
> www.softwaretoolhouse.com
>
>
>
>
>
> *From:* Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com
> <ben.cher...@softwaretoolhouse.com>]
> *Sent:* May-25-17 9:10 AM
> *To:* 'arslist@ARSLIST.ORG' <arslist@ARSLIST.ORG>
> *Subject:* RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT
> using UTF-8 on their DB on anything > 7.6.04?
>
>
>
> Hi Fred,
>
>
>
> Thanks for your reply.
>
>
>
> I have no access at all to the client Windows machine or the Linux server
> – not even WebEx.  As for the DB, I expect the BMC software is not lying
> when it reports its character set.  The info below is from the values of
> the server info stuff which Meta-Update ma

RE: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

[Ben Chernys]

Hi LJ,

 

I am getting this from my client – although I was involved in the support 
ticket.  So, I didn’t hear it from the horse’s mouth.  I was told “around 9.5”.

 

It doesn’t really matter when it is fixed.  The OOTB ITSM apps generally do not 
have umlauts in the “Query Fields” defined for the forms.  Meta-Update works 
around the problem by supplying its own QueryFields list.  This bug is rare.

 

I have two clients with this problem.  One modified HPD:Help Desk’s Query 
Fields list to have fields whose values include umlauts.  The other has their 
own app.

 

In fact, it does make sense.  I have heard statements like this from many many 
software companies and I myself have made statements like this.  Remedy is a 
big piece of software and all fixes need to be tracked and scheduled.  It just 
indicates that this is currently planned to be fixed in that release.  Once it 
is assigned and investigated, times may change.

 

Cheers

Ben

 

From: ARSList [mailto:arslist-boun...@arslist.org] On Behalf Of LJ LongWing
Sent: January-31-18 8:08 AM
To: ARSList <arslist@arslist.org>
Subject: Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" 
with workaround; BMC Bug raised; fix ~ 9.5

 

Ben,

Your statement regarding being fixed around '9.5' doesn't make any sense to 
medid whoever you talked to SAY 9.5 or did they say 'next release', or more 
likely 'future version'?

 

On Wed, Jan 31, 2018 at 7:59 AM, Ben Chernys <ben.cher...@softwaretoolhouse.com 
<mailto:ben.cher...@softwaretoolhouse.com> > wrote:

FYI

 

BMC has raised this as a bug and is expecting to fix it around 9.5.

 

Cheers

Ben

 

From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com 
<mailto:ben.cher...@softwaretoolhouse.com> ] 
Sent: May-29-17 7:57 AM
To: 'arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG> ' <arslist@ARSLIST.ORG 
<mailto:arslist@ARSLIST.ORG> >
Subject: RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using 
UTF-8 on their DB on anything > 7.6.04? - "solved" workaround

 

Hi All,

 

I have heard back from the customer.  The work-around does indeed work around 
the problem.  It seems the bug is related only to building the short 
description string for an ARGetListEntry response.  The server comes back to 
the client and the client responds that it can’t decode the result (ARERR 992) 
if and only if the any of the result’s descriptions have umlauts.  

 

Meta-Update uses that string in its messaging:  Qry 1 of x: default short 
description (get fields) from the record.  Simple solution for those using the 
API is to override the default short description generation with a single field 
known to not contain any special characters such as umlauts (such as ‘1’).

 

This bug seems to have been introduced in 9.1 or at least this customer did not 
experience it before the upgrade to 9.1.0 – from which version I know not – but 
running on HP-UX. :)  I haven’t tested in on my servers (9.1.02, 8.1, …) to see 
when it was introduced and the fact that I run UTF-8 may affect the test.

 

Cheers

Ben

www.softwaretoolhouse.com <http://www.softwaretoolhouse.com> 

 

 

From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] 
Sent: May-25-17 9:10 AM
To: 'arslist@ARSLIST.ORG <mailto:arslist@ARSLIST.ORG> ' <arslist@ARSLIST.ORG 
<mailto:arslist@ARSLIST.ORG> >
Subject: RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using 
UTF-8 on their DB on anything > 7.6.04?

 

Hi Fred,

 

Thanks for your reply.

 

I have no access at all to the client Windows machine or the Linux server – not 
even WebEx.  As for the DB, I expect the BMC software is not lying when it 
reports its character set.  The info below is from the values of the server 
info stuff which Meta-Update makes available to you on startup.  The ./arsys 
reports LANG, LC_ALL with en_US.UTF-8

 

I did check on my server and was surprised that the machine, the Remedy user, 
etc seems to be on utf8 and the DB on utf16 – and a different locale as well.

 

I suppose it would be easy enough to look at ITSM’s normal forms and stick an 
umlaut in one of their query results fields.  Your email has spurred that idea, 
so I thank you for that.  I am still waiting the results of the enhancement 
(step 1) and patch (if matching the locale and charset fails) I gave the 
client.  The patch will circumvent the whole problem as the query will only 
return field 1 as its short description.

 

I am unclear what strings to set on the client for locale and charset to match. 
 In particular relating to the “iso” prefix:  de_DE.iso-8859-15 or de_DE.8859-15

 

Thanks again Fred.  I know I can count on you when it comes to Linux and 
Oracle.  Is Axton still around?  My 8.1.02, 9.1.02 servers are running that, 
though my 7.6.04 is running Windows (on XP64 I believe!) MS SQL server.  I 
upgraded a copy of 8.1 to make my 9.1.02 but I think I need to b

Re: FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

[LJ LongWing]

Ben,
Your statement regarding being fixed around '9.5' doesn't make any sense to
medid whoever you talked to SAY 9.5 or did they say 'next release', or
more likely 'future version'?

On Wed, Jan 31, 2018 at 7:59 AM, Ben Chernys <
ben.cher...@softwaretoolhouse.com> wrote:

> FYI
>
>
>
> BMC has raised this as a bug and is expecting to fix it around 9.5.
>
>
>
> Cheers
>
> Ben
>
>
>
> *From:* Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com]
> *Sent:* May-29-17 7:57 AM
> *To:* 'arslist@ARSLIST.ORG' 
> *Subject:* RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT
> using UTF-8 on their DB on anything > 7.6.04? - "solved" workaround
>
>
>
> Hi All,
>
>
>
> I have heard back from the customer.  The work-around does indeed work
> around the problem.  It seems the bug is related only to building the short
> description string for an ARGetListEntry response.  The server comes back
> to the client and the client responds that it can’t decode the result
> (ARERR 992) if and only if the any of the result’s descriptions have
> umlauts.
>
>
>
> Meta-Update uses that string in its messaging:  Qry 1 of x: default short
> description (get fields) from the record.  Simple solution for those using
> the API is to override the default short description generation with a
> single field known to not contain any special characters such as umlauts
> (such as ‘1’).
>
>
>
> This bug seems to have been introduced in 9.1 or at least this customer
> did not experience it before the upgrade to 9.1.0 – from which version I
> know not – but running on HP-UX. :)  I haven’t tested in on my servers
> (9.1.02, 8.1, …) to see when it was introduced and the fact that I run
> UTF-8 may affect the test.
>
>
>
> Cheers
>
> Ben
>
> www.softwaretoolhouse.com
>
>
>
>
>
> *From:* Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com
> ]
> *Sent:* May-25-17 9:10 AM
> *To:* 'arslist@ARSLIST.ORG' 
> *Subject:* RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT
> using UTF-8 on their DB on anything > 7.6.04?
>
>
>
> Hi Fred,
>
>
>
> Thanks for your reply.
>
>
>
> I have no access at all to the client Windows machine or the Linux server
> – not even WebEx.  As for the DB, I expect the BMC software is not lying
> when it reports its character set.  The info below is from the values of
> the server info stuff which Meta-Update makes available to you on startup.
> The ./arsys reports LANG, LC_ALL with en_US.UTF-8
>
>
>
> I did check on my server and was surprised that the machine, the Remedy
> user, etc seems to be on utf8 and the DB on utf16 – and a different locale
> as well.
>
>
>
> I suppose it would be easy enough to look at ITSM’s normal forms and stick
> an umlaut in one of their query results fields.  Your email has spurred
> that idea, so I thank you for that.  I am still waiting the results of the
> enhancement (step 1) and patch (if matching the locale and charset fails) I
> gave the client.  The patch will circumvent the whole problem as the query
> will only return field 1 as its short description.
>
>
>
> I am unclear what strings to set on the client for locale and charset to
> match.  In particular relating to the “iso” prefix:  de_DE.iso-8859-15 or
> de_DE.8859-15
>
>
>
> Thanks again Fred.  I know I can count on you when it comes to Linux and
> Oracle.  Is Axton still around?  My 8.1.02, 9.1.02 servers are running
> that, though my 7.6.04 is running Windows (on XP64 I believe!) MS SQL
> server.  I upgraded a copy of 8.1 to make my 9.1.02 but I think I need to
> build one from scratch in both Linux and Windows.
>
>
>
> Thanks again,
>
> Ben
>
>
>
>
>
> *From:* Action Request System discussion list(ARSList) [
> mailto:arslist@ARSLIST.ORG ] *On Behalf Of *Grooms,
> Frederick W
> *Sent:* May-24-17 8:52 PM
> *To:* arslist@ARSLIST.ORG
> *Subject:* Re: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT
> using UTF-8 on their DB on anything > 7.6.04?
>
>
>
> **
>
> From the bin directory, what do you get if you run
>
> > ./arsystem env | sort
>
>
>
> Look at the values of
>
>CLIENT_LOCALE en_us.8859-1
>
>LANG C
>
>LC_ALL  C
>
>
>
> What is the database character set you see when you run the following
>
> SELECT * FROM NLS_DATABASE_PARAMETERS ;
>
>
>
> We currently have a 9.1.02.003 system Red Hat Enterprise Linux Server
> release 7.2 (Maipo) (Linux 3.10.0-327.36.1.el7.x86_64)
>
> Using   NLS_CHARACTERSET   US7ASCII
>
>
>
> I have not seen your error
>
> Fred
>
>
>
>
>
> *From:* Action Request System discussion list(ARSList) [
> mailto:arslist@ARSLIST.ORG ] *On Behalf Of *Ben
> Chernys
> *Sent:* Wednesday, May 24, 2017 7:05 PM
> *To:* arslist@ARSLIST.ORG
> *Subject:* ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT
> using UTF-8 on their DB on anything > 7.6.04?
>
>
>
> **
>
> Hi Folks,
>
>
>
> I 

FYI: ARERR 91 RPC: Can't decode result - on 9.1.00; - "solved" with workaround; BMC Bug raised; fix ~ 9.5

[Ben Chernys]

FYI

 

BMC has raised this as a bug and is expecting to fix it around 9.5.

 

Cheers

Ben

 

From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] 
Sent: May-29-17 7:57 AM
To: 'arslist@ARSLIST.ORG' 
Subject: RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using
UTF-8 on their DB on anything > 7.6.04? - "solved" workaround

 

Hi All,

 

I have heard back from the customer.  The work-around does indeed work
around the problem.  It seems the bug is related only to building the short
description string for an ARGetListEntry response.  The server comes back to
the client and the client responds that it can't decode the result (ARERR
992) if and only if the any of the result's descriptions have umlauts.  

 

Meta-Update uses that string in its messaging:  Qry 1 of x: default short
description (get fields) from the record.  Simple solution for those using
the API is to override the default short description generation with a
single field known to not contain any special characters such as umlauts
(such as '1').

 

This bug seems to have been introduced in 9.1 or at least this customer did
not experience it before the upgrade to 9.1.0 - from which version I know
not - but running on HP-UX. :)  I haven't tested in on my servers (9.1.02,
8.1, .) to see when it was introduced and the fact that I run UTF-8 may
affect the test.

 

Cheers

Ben

www.softwaretoolhouse.com  

 

 

From: Ben Chernys [mailto:ben.cher...@softwaretoolhouse.com] 
Sent: May-25-17 9:10 AM
To: 'arslist@ARSLIST.ORG' 
>
Subject: RE: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using
UTF-8 on their DB on anything > 7.6.04?

 

Hi Fred,

 

Thanks for your reply.

 

I have no access at all to the client Windows machine or the Linux server -
not even WebEx.  As for the DB, I expect the BMC software is not lying when
it reports its character set.  The info below is from the values of the
server info stuff which Meta-Update makes available to you on startup.  The
./arsys reports LANG, LC_ALL with en_US.UTF-8

 

I did check on my server and was surprised that the machine, the Remedy
user, etc seems to be on utf8 and the DB on utf16 - and a different locale
as well.

 

I suppose it would be easy enough to look at ITSM's normal forms and stick
an umlaut in one of their query results fields.  Your email has spurred that
idea, so I thank you for that.  I am still waiting the results of the
enhancement (step 1) and patch (if matching the locale and charset fails) I
gave the client.  The patch will circumvent the whole problem as the query
will only return field 1 as its short description.

 

I am unclear what strings to set on the client for locale and charset to
match.  In particular relating to the "iso" prefix:  de_DE.iso-8859-15 or
de_DE.8859-15

 

Thanks again Fred.  I know I can count on you when it comes to Linux and
Oracle.  Is Axton still around?  My 8.1.02, 9.1.02 servers are running that,
though my 7.6.04 is running Windows (on XP64 I believe!) MS SQL server.  I
upgraded a copy of 8.1 to make my 9.1.02 but I think I need to build one
from scratch in both Linux and Windows.

 

Thanks again,

Ben

 

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Grooms, Frederick W
Sent: May-24-17 8:52 PM
To: arslist@ARSLIST.ORG  
Subject: Re: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using
UTF-8 on their DB on anything > 7.6.04?

 

** 

>From the bin directory, what do you get if you run

> ./arsystem env | sort 

 

Look at the values of

   CLIENT_LOCALE en_us.8859-1

   LANG C

   LC_ALL  C

 

What is the database character set you see when you run the following   

SELECT * FROM NLS_DATABASE_PARAMETERS ;   

 

We currently have a 9.1.02.003 system Red Hat Enterprise Linux Server
release 7.2 (Maipo) (Linux 3.10.0-327.36.1.el7.x86_64) 

Using   NLS_CHARACTERSET   US7ASCII

 

I have not seen your error

Fred

 

 

From: Action Request System discussion list(ARSList)
[mailto:arslist@ARSLIST.ORG] On Behalf Of Ben Chernys
Sent: Wednesday, May 24, 2017 7:05 PM
To: arslist@ARSLIST.ORG  
Subject: ARERR 91 RPC: Can't decode result - on 9.1.00; Anyone NOT using
UTF-8 on their DB on anything > 7.6.04?

 

** 

Hi Folks,

 

I have a customer using what I think of as a first.  An Oracle DB with
charset 

DB_CHAR_SET := (11) iso-8859-15

 

This is against ARS 9.1.00 201610281101 running on Linux
2.6.32-573.3.1.el6.x86_64 against Oracle 12.1.0.2.0 - 64bit Production.

 

I issue a Query and the response includes the default Form based list of
query fields.  There apparently is no way to request none.  You can override
the default which is the obvious work-around and will be tested shortly.
Presumably, you may say the