Update:
I changed the subject to something harmless in the original source ticket in
RT2, and re-exported. This got me further - the ticket was created at least
in the RT3 instance. But the subject was still huge & binary-like in the
transactions lower down in the ticket, and the import still failed, just a
few microseconds later 
Deleting the offending ticket seems to have worked around the problem.
-DarrenFrom: “Darren Nickerson” darren@dazza.org
To: rt-users@lists.fsck.com
Sent: Sunday, February 29, 2004 10:13 PM
Subject: [rt-users] rt2-to-rt3-1.23 ORACLE import fails with:
[crit]:Attempting to add a member to a group which wasn’t loaded.‘oops’ and
ORA-01406
Folks,
I’ve been trying for much of the weekend to convince ‘dumpfile-to-rt-3.0’
to
import the dump I made from RT-2.0.13, but I haven’t made any progress in
even understanding the problem, much less fixing it. The RT::StockAnswer
from Jesse was “upgrade to perl-5.8.3 because 5.6.1 sucks”, but after
dragging my server kicking and screaming through the upgrade to 5.8.3, I’m
no better off.I’ve included the output from the import tool below, and I’ve also
attached
it to this email in case my mailer mangles the formatting, or the high-bit
characters. Can anyone help me understand how to troubleshoot this? I’m
not
sure if the ORA-01496 error is the root cause here, or whether the earlier
message about adding a member to an unloaded group is relevant.Oracle’s Metalink has the following to say about that error:
Error: ORA 1406
Text: fetched column value was truncated
Cause: In a host language program, a FETCH operation was forced to
truncate
a
character string.
The program buffer area for this column was not large enough to
contain the entire string.
The cursor return code from the fetch was +3.
Action: Increase the column buffer area to hold the largest column value
or
perform other appropriate processing.Any bells ringing? Is this similar to MySQL’s maximum packet size? Almost
sounds like it’s a limitation in the perl code though instead of the
database, at least from the description above. Is it possible the subject
line is overflowing things?? It looks suspiciously long and … well
binary.Assume for a moment that there’s no way to fix this. After a close
examination of the ticket I really don’t care if we get it into the new
database or not. Is there any way to surgically remove it from the RT2
dump
I created so that I can re-run the import and just skip past this one?Thanks in advance for any assistance/advice/commiseration.
-Darren
(output from import follows)
[snip]
.t-79
.t-80
.t-81
.t-82
.t-83
[Mon Mar 1 01:20:55 2004] [crit]: Attempting to add a member to a group
which wasn’t loaded. ‘oops’ (/usr/local/rt3/lib/RT/Group_Overlay.pm:934)
Couldn’t create ticket HASH(0x9079d34) $VAR1 = {
‘Status’ => ‘deleted’,
‘Queue’ => ‘sales’,
‘InitialPriority’ => ‘50’,
‘Started’ => ‘2002-04-18 14:47:38’,
‘Starts’ => ‘1970-01-01 00:00:00’,
‘_RecordTransaction’ => ‘0’,
‘id’ => 83,
‘LastUpdated’ => ‘2002-04-18 14:47:38’,
‘Requestor’ => [
‘gb@lists.debian.org’
],
‘Subject’ =>
"\x{c8}\x{bf}\x{d5}\x{be}\x{fc}\x{d3}\x{a2}\x{d0}\x{db}\x{c4}\x{a3}\x{b7}\x{
b6}sjgchlshang\x{cc}\x{d8}\x{c1}\x{a2}\x{cd}\x{ac}\x{d6}\x{be}\x{c1}\x{f9}\x
{ca}\x{ae}sjbdhesjfnjfang\x{cd}\x{f5}\x{b9}\x{db}\x{c0}\x{bd}chyang\x{cd}\x{
f5}\x{b2}\x{aa}\x{d1}\x{f9}\x{c6}\x{b7}zhoushizhao2sjhlyzihuichang\x{ca}\x{d
6}\x{ca}\x{e9}\x{c2}\x{b3}\x{d1}\x{b8}\x{cd}\x{cf}\x{c0}\x{ad}\x{bb}\x{fa}\x
{cc}\x{e5}\x{d3}\x{fd}\x{bd}\x{da}\x{d1}\x{f9}\x{c6}\x{b7}\x{ca}\x{d6}\x{ca}
\x{e9}\x{c2}\x{b3}\x{d1}\x{b8}\x{c8}\x{ab}\x{b9}\x{fa}\x{ce}\x{c0}\x{c9}\x{f
a}\x{bb}\x{e1}\x{d2}\x{e9}\x{c7}\x{e0}\x{c4}\x{ea}\x{cd}\x{c5}\x{b5}\x{da}\x
{d2}\x{bb}\x{b4}\x{ce}\x{c8}\x{cb}\x{c3}\x{f1}\x{d3}\x{a2}\x{d0}\x{db}\x{cd}
\x{c5}\x{bd}\x{e1}\x{bf}\x{b9}\x{b4}\x{f3}\x{bd}\x{a8}\x{d6}\x{fe}\x{d0}\x{a
3}\x{c9}\x{e1}\x{cd}\x{f5}\x{b9}\x{db}\x{c0}\x{bd}\x{cc}\x{e5}\x{d3}\x{fd}\x
{d7}\x{dc}\x{bb}\x{e1}sjdlrh",
‘FinalPriority’ => ‘50’,
‘Creator’ => ‘1922’,
‘Owner’ => ‘10’,
‘LastUpdatedBy’ => ‘1174’,
‘EffectiveId’ => ‘83’,
‘Created’ => ‘2002-04-18 08:17:04’,
‘Priority’ => ‘50’,
‘Due’ => ‘2002-04-23 08:17:04’
};
Couldn’t create attachment
$VAR1 = {
‘Subject’ =>
'ȿվ�Ӣ��ģ��sjgchlshang����ͬ־��ʮsjbdhesjfnjfang������chyang������Ʒzhou
shizhao2sjhlyzihuichang����³Ѹ��������������Ʒ����³Ѹȫ���������������ŵ��
�������Ӣ���ŽΌ����У�������������ܻ�sjdlrhuanjiefangnanjingjianggangs
ha
n_nnj����ͬѧ��shengde����’,
‘ContentType’ => ‘multipart/related’,
‘Headers’ => 'Return-Path: gb@lists.debian.org
Delivered-To: sales_hylafax@polaris.dazza.org
Received: from YUBIN (unknown [210.21.203.194]) by polaris.dazza.org
(Postfix) with SMTP id EC466254019 for sales@hylafax.org; Thu, 18 Apr
2002
01:17:00 -0700 (PDT)
From: gb@lists.debian.org
Subject:
ȿվ�Ӣ��ģ��sjgchlshang����ͬ־��ʮsjbdhesjfnjfang������chyang������Ʒzhous
hizhao2sjhlyzihuichang����³Ѹ��������������Ʒ����³Ѹȫ���������������ŵ�һ
������Ӣ���ŽΌ����У�������������ܻ�sjdlrhuanjiefangnanjingjianggangshan
_nnj����ͬѧ��shengde�����mail.hylafax.org.�Ž�
MIME-Version: 1.0
Content-Type: multipart/related; type=“multipart/alternative”;
boundary=“====ABC123456j7890DEF====”
X-Priority: 3
X-Msmail-Priority: Normal
X-Unsent: 1
Message-Id: 20020418081700.EC466254019@polaris.dazza.org
Date: Thu, 18 Apr 2002 01:17:00 -0700 (PDT)
To: undisclosed-recipients:;
',
‘Creator’ => ‘82’,
‘Parent’ => ‘0’,
‘Created’ => ‘2002-04-18 08:17:04’,
‘id’ => ‘1024’,
‘TransactionId’ => ‘779’
};ORA-24345: A Truncation or null fetch error occurred (DBD ERROR: ORA-01406
error on field 5 of 12, ora_type 1)
[Mon Mar 1 01:20:55 2004] [crit]: Died at ./dumpfile-to-rt-3.0 line 714.
(/usr/local/rt3/lib/RT.pm:254)
[root@polaris rt2-to-rt3-1.23]#
rt-users mailing list
rt-users@lists.bestpractical.com
The rt-users ArchivesHave you read the FAQ? The RT FAQ Manager lives at http://fsck.com/rtfm