[Rt-devel] Import from 2.0.13 to 3.20 is not correct

Joop van de Wege JoopvandeWege at mococo.nl
Tue Jul 13 04:49:40 EDT 2004


Hello All,

Currently I'm trying out the new RT 3.2.0 release and I'm importing my
data from a RT 2.13 install which is using Oracle as a backend into the
new install which is also using Oracle as  backend, Oracle9i to be
precise.

I modified the RT2 instance to work with Oracle and haven't had any
problems with it that includes attachments getting into the database and
getting them out. I modified the schema to use CBLOB's and modified
SearchBuilders Handle/Oracle.pm to use unsafe binary blobs. This results
into base64 encoded attachments in the database which is correct.
When I export the RT2 instance using rt2-rt3 1.23 I get dumps in which
it says Content-Transfer-Encoding: base64 followed by the binary data,
in my sample case a zip file. Sofar this looks correct and according to
rt2-dumpfile this is also expected behaviour.
The problem is in the import into the RT3 instance. Here SearchBuilder
also assumes unsafe binary blobs for Oracle and I would have expected to
see base64 encoded data in the attachments table in the Content column
but instead I find binary data and I'm not sure what has happened to it.
The zip header looks OK but strangely enough a couple of bytes have
change among them a B9 to BF, checked through export function of Oracle.
It looks like the dumpfile-tp-rt3.0 is doing something wrong or the code
in RT3.2.0 is not doing the right thing. If I look at that ticket from
the WebUI then I see that its size is just 29bytes instead of ~2Kb and
clicking on it and saving it shows me really some garbage which isn't
recognisable as a zip file at all.

Anyone who can comment on this? Jesse?

Thanks in advance,

Joop


-- 
Joop van de Wege <JoopvandeWege at mococo.nl>



More information about the Rt-devel mailing list