[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