Dumpfile-to-rt-3.0, incremental import failed

RT Users
1

Hi,

we would like to update from rt 2.0.11 to 3.8.8.

Using dumpfile-to-rt-3.0, a full export/import works fine.
The incremental import ended with the following error:

t-57701: ww[Mon Mar 7 14:26:48 2011] [crit]:
Couldn’t set EffectiveId: That is already the current value
(/opt/rt3/lib/RT/Ticket_Overlay.pm:504)

Couldn’t create TICKET: Ticket could not be created due to an internal
error$VAR1 = {
‘Status’ => ‘stalled’,
‘Queue’ => ‘support’,
‘Started’ => ‘2011-03-01 17:25:31’,
‘Starts’ => ‘1970-01-01 00:00:00’,
‘_RecordTransaction’ => ‘0’,
‘id’ => ‘57701’,
‘LastUpdated’ => ‘2011-03-01 17:25:31’,
‘Requestor’ => [
‘36060’
],
‘Cc’ => [
‘24054’
],
‘Subject’ => ‘xxxxxxxxx’,
‘Creator’ => ‘36060’,
‘Owner’ => ‘65444’,
‘EffectiveId’ => ‘57701’,
‘LastUpdatedBy’ => ‘57822’,
‘Created’ => ‘2010-12-10 18:47:09’,
‘Due’ => ‘2010-12-10 18:47:09’
};
[Mon Mar 7 14:26:48 2011] [crit]: Died at /usr/bin/dumpfile-to-rt-3.0
line 716. (/opt/rt3/lib/RT.pm:382)
Died at /usr/bin/dumpfile-to-rt-3.0 line 716.

** Code around /opt/rt3/lib/RT.pm:382 looks like

#Set the ticket’s effective ID now that we’ve created it.

my ( $val, $msg ) = $self->__Set(
    Field => 'EffectiveId',
    Value => ( $args{'EffectiveId'} || $id )
);
unless ( $val ) {
    $RT::Logger->crit("Couldn't set EffectiveId: $msg");
    $RT::Handle->Rollback;
    return ( 0, 0,
        $self->loc("Ticket could not be created due to an internal

error")
);
}

I found a thread concerning this issue

uldn’t%20set%20EffectiveId:%20That%20is%20already%20the%20current%20valu
e;#89660
but the solution was told to the community.

Is there a way to fix this problem with the “incremental import” ?

Kind regards
Danny

2

Hi,

we would like to update from rt 2.0.11 to 3.8.8.

Using dumpfile-to-rt-3.0, a full export/import works fine.
The incremental import ended with the following error:

I found a thread concerning this issue

Carbon60: Managed Cloud Services
uldn’t%20set%20EffectiveId:%20That%20is%20already%20the%20current%20valu
e;#89660
but the solution was told to the community.

Actually, Dom pointed out the problem in that thread, although I’m not
entirely sure why it fails to look up properly (probably a loading
order bug).

What happens if you change the line

BEGIN { $RT::DontCacheSearchBuilderRecords = 1; }

to instead use RT->Config->Set(‘DontCacheSearchBuilderRecords’, 1);

You can also go pull Dom’s more complete patch from his github,
although I think when that hits master it will be slightly different.

-kevin