[rt-users] [crit]: Died at ./dumpfile-to-rt-3.0 line 714.

[Julian C. Dunn]

On Wed, 2005-06-29 at 10:27 -0500, Law Mitchell wrote:

> anyone have an idea on how to work around/fix this error? ...upgrading
> from rt2.0.15 to rt-3.0.12 using a postgres8.x db.
> 
> t-617
> t-618
> t-619
> t-620
> t-621
> Couldn't create attachment 
> $VAR1 = {
>           'Subject' => '',
>           'ContentType' => 'text/html',
>           'Headers' => 'Content-Type: text/html; charset="ISO-8859-1"
> Content-Transfer-Encoding: quoted-printable
> ',
>           'Creator' => '70',
>           'Parent' => '965',
>           'Created' => '2002-07-11 20:10:19+00',
>           'id' => '967',
>           'ContentEncoding' => 'none',
>           'TransactionId' => '1886'
>         };
> 
> ERROR:  invalid byte sequence for encoding "UNICODE": 0xdf3c
> 
> [Wed Jun 29 15:19:20 2005] [crit]: Died at ./dumpfile-to-rt-3.0 line 714.
>  (/opt/rt3/lib/RT.pm:255)

I have never had a complete response on rt-users on how to work around
this issue; when we upgraded our RT installation to 3.2.2 I had to hack
the exporter script (the following is an excerpt from the transaction
history in our ticketing system for the job):

----------------------
I have bludgeoned the importer into working by adding the statement:

# Hacked by Julian
$RT::Handle->SimpleQuery("SET CLIENT_ENCODING TO 'LATIN1'");

into the dumpfile-to-rt3.0 script. Note that one can't translate
SQL_ASCII directly into UNICODE per the docs
(http://www.postgresql.org/docs/7.4/static/multibyte.html) so I chose
LATIN1 (ISO-8859-1) instead, in the hopes that this will work.

----------------------

However, this broke most, if not all, the historical attachments. If you
can live with that (as we decided we could), then this will at least
make the import/export work.

- Julian

-- 
-- Julian C. Dunn, B.A.Sc, P.Eng.  <Julian_Dunn at cbc.ca>
-- Platform Administrator, CBC.ca Production & Operations
-- Office: 2C310-Q  *  Tel.: (416) 205-3311 x5592