I believe that this is a limitation of the Progress DB. Here is a response I got from Tech-services on what I think is a similar issue.
> > ====================================================================
> > 9.4 Creating and Running a Unicode Application
> >
> > Creating and running an application that uses Unicode is not difficult.
> > Here is an example of creating and running an application consisting of a
> > database server, a graphical client, and a UTF-8 database.
> >
> > Since UTF-8 is supported by the Progress database server but not by the
> > Progress graphical or character client:
> >
> > Each graphical or character client must start up in a code page other than
> > UTF-8.
> >
> > The programmer must ensure that a graphical or character client accesses
> > only records in a compatible code page.
> > ...
> >
> > 2.Design queries that access only records that use client's code page.
> >
> > One way to do this is for tables to have a field that indicates the
> > record's code page. When records are added, the field is populated. When
> > the database is queried, the query references the code page field in order
> > to return only those records in the client's code page.
> >
> > Imagine that the Customer table of the Sports database has a field that
> > indicates the code page. A client whose codepage is SESSION:CPINTERNAL
> > might submit a query similar to the following:
> >
> > FOR EACH customer WHERE codepage = SESSION:CPINTERNAL:
> >
> > DISPLAY name address city country comments.
> >
> > END.
> > ====================================================================
> >
> >
> > Once you have built your database and indexes correctly, the following
> > situation occurs when you try to delete or update an indexed value in an
> > incompatible codepage:
> >
> > The field is read in from the database to the client, which does a
> > conversion from utf-8 to iso8859-1. Any Chinese characters will be
> > converted to question marks ('?'). The delete or update will then build an
> > index key using this value, which will fail.
> >
> > This is not a bug. If you cannot label the codepage (or codepage family,
> > such as Eastern Europe [iso8859-2, 1250,...], Western Europe[iso8859-1,
> > 1252,ibm850,...], etc) of your records, you can see if the field contains
> > unexpected question marks. However, I don't know of a way in the 4gl to
> > distinguish a valid question mark from an invalid one in a database field
> > that comes from a utf-8 database into a non-utf-8 client.
> >
> > If you do the delete or update with no-error, you can avoid the error
> > message. You can then check the error status and decide what to do, but
> > you
> > will not be able to alter the record.
