[rt-users] dumpfile-to-rt-3.0 problem: parser: unterminatedquotedstring

[Alexei Barantsev]

Hi, 

Yes, that is just what I did - I always transferred to RT3
$att->_Value($att_param) whatever it is 'Content' or not, and that does
work.
Now I have all my old base64-encoded attachments also base64-encoded in new
RT3 database.
And RT3 web-interface (or, more probably, RT library behind it) does all the
magic to decode it and return real binary code to the browser.
I don't know about other databases but for Postgres content decoding during
migration should be disabled.

Regards,
Alexei

  > -----Original Message-----
  > From: rt-users-bounces at lists.bestpractical.com 
  > [mailto:rt-users-bounces at lists.bestpractical.com] On Behalf 
  > Of Joop van de Wege
  > Sent: Monday, July 19, 2004 5:09 PM
  > To: rt-users at lists.bestpractical.com
  > Subject: [rt-users] dumpfile-to-rt-3.0 problem: parser: 
  > unterminatedquotedstring
  > 
  > > Hi,
  > > 
  > > I've detected the reason of the problem, but I don't know how to 
  > > woraroud it.
  > > The cause is that the attachment is marked as 
  > base64-encoded while IT 
  > > IS NOT!
  > > It was base64-encoded in the RT2 database, I checked that up with 
  > > direct SQL query.
  > > But serialized version of the ticket in the exported form 
  > contains 
  > > decoded content of the attachment.
  > > I can't find decoding in rt-2.0-to-dumpfile script so it must be 
  > > performed somewhere in the RT library (probably 
  > $att->Content() do 
  > > that???). So dumpfile-to-rt-3.0 have to encode it back to 
  > base64 to be 
  > > able to store it to the database.
  > > 
  > > In this case the problem must be in this piece of code of the 
  > > rt-2.0-to-dumpfile script:
  > > 
  > >                   my $att_param ( sort keys %{ 
  > > $att->{_AccessibleCache} } ) {
  > >                         if ($att_param eq 'Content') {
  > >                                 $att_ds->{$att_param} = 
  > > $att->Content();
  > > 
  > >                          } else {
  > > 
  > >                                 $att_ds->{$att_param} =
  > > $att->_Value($att_param)
  > >                                         if (defined 
  > > $att->_Value($att_param) );
  > >                          }
  > > 
  > > and actualy there is no need to decode attachment content 
  > if it is 
  > > base64-encoded?
  > You're right about that and the solution is simple. Just 
  > change the following line:
  > >                         if ($att_param eq 'Content') {
  > >                                 $att_ds->{$att_param} = 
  > > $att->Content();
  > into
  >             if ($att_param eq 'Content') {
  >                      $att_ds->{$att_param} = 
  > $att->_Value($att_param);
  > 
  > Or just dump the whole if construction since it is of no 
  > use anymore.
  > What happens is that the export is done using the base64 
  > encoded data and not the binary data together with the 
  > header ContentType set to base64. The import tool is much 
  > harder to convince todo something special thats why I use 
  > this patch. The import tool just import the data encoded 
  > together with the correct encoding type and puts it all 
  > nicely into the database. Viewing the tickets this way and 
  > clicking on the download links gives me nicely the binary 
  > data on disk ;-)
  > 
  > Jesse, feel free to enhence rt2-to-rt3 with this information.
  > Personally I would have liked a solution where the export 
  > does the right thing, namely what it does originally since 
  > then the exported data then looks like the original mail 
  > with binary data but I can't get the encoding type right so 
  > that the import side does the right thing. Maybe when I 
  > spend much, much more time on it but this just works and I 
  > only need to get my data into RT3.
  > 
  > Joop
  > 
  > 
  > 
  > --
  > Joop van de Wege <JoopvandeWege at mococo.nl>
  > 
  > _______________________________________________
  > http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
  > 
  > Be sure to check out the RT wiki at http://wiki.bestpractical.com
  >