[ic] Upgrade procedure

Peter peter at pajamian.dhs.org
Mon Jun 15 17:00:44 UTC 2009

On 06/15/2009 07:44 AM, Grant wrote:
>>>>> Database variable scalar parameter VARIABLE.TXT redefined to "TAB", was "TAB".
>>>> You have a duplicate Database line for your variable database.  check
>>>> your catalog.cfg and included files (including files in the dbconf
>>>> directory and subdirectories).
>>> You're right, I had variable.dbm in both dbconf/default_db and
>>> dbconf/mysql.  I noticed I also have identical access.dbm and
>>> mv_metadata.dbm files in those locations.  Does variable have special
>>> handling in this case?
>> Only the ones in the mysql directory should get pulled in.  Check your
>> catalog.cfg for an extra Database line for the variable file.
> The message actually disappeared after I removed the line from
> dbconf/default_db/variable.dbm.  A bug maybe?

Only one of the two directories should get pulled in from your
catalog.cfg, so check that and any files included from that.  Certain
variables set in the variables.txt file itself can control the flow of
things in catalog.cfg, explicitly where control of which db is pulled in
is concerned.

>>>>> Warning while compiling UserTag 'ups_query':
>>>>> "my" variable $result masks earlier declaration in same scope at
>>>>> /usr/lib/perl5/vendor_perl/5.8.8/Business/UPS.pm line 97, <SYSTAG>
>>>>> line 154.
>>>> This is an issue with Business::UPS and needs to be taken up with the
>>>> author of that module.  It is porobably safe to ignore the warning, though.
>>> OK but should that usertag be disincluded from IC since it has a problem?
>>> code/UserTag/ups_query.tag
>> If you're not using ups then you should be able to exclude the usertag
>> without problems.  I would not consider the warning you mention to be
>> enough of a "problem" to merit removing the usertag from IC.
> A fresh installation of IC throwing a warning upon start/restart seems
> to me like it should be fixed, but it's not a big deal.  I renamed
> ups_query.tag to ups_query.tag.conflict and the warning disappeared.

Yes and no.  The warning is not coming from any Interchange code itself,
but from the module.  It is even possible that you have a specific
version of the module which throws the warning.  At any rate, given a
choice between having functionality and a warning or having to implement
such a broad range of functionality ourselves or removing the
functionality generally having the functionality and the warning wins out.

If it were an Interchange bug causing the warning then you would be correct.

> Thanks a lot for all your advice.  The upgrade went very smoothly thanks to you.

You're welcome :-)


More information about the interchange-users mailing list