I did a remote copydb from a Linux 2.6 installation on a 6.4 database.
The COPYDB (internally) does a sql-statement which produces the
following error:

E_US0834 line 1, Table 'iipermits' owned by '$ingres' does not contain
column 'table_name'.

My thought: the view iipermits in a 2.6 installation has got a column
named table_name and on the 6.4 it does not.

But when I looked at the iipermits on the 2.6 installation I could (and
still can't) not find a column named table_name.

The complete error:
INGRES COPYDB Copyright 2003 Computer Associates Intl, Inc.^M
Unload directory is '/var/opt/monica/data/sita_utr_0605'.
Reload directory is '/var/opt/monica/data/sita_utr_0605'.
There is one table owned by user 'sita'.
E_US0834 line 1, Table 'iipermits' owned by '$ingres' does not contain
column 'table_name'.
(Wed Jun 15 11:35:38 2005)

So after the tables is quits.
Views and procedures wil not be copied out.

I am glad that the database on which I do the copyout does not have
views or proceudres.

I just want to understand it and want to know to prevent possible
future errors.

thanks!

Erwin

Hi Martin,

It only gives the error when it's a copydb on table level. A complete
datasbe copydb works oke.
There are no errors in the II2.6 errlog. I do not have direct access to
the 6.4 machines.

ET

eteunisse wrote:
> I did a remote copydb from a Linux 2.6 installation on a 6.4 database.
> The COPYDB (internally) does a sql-statement which produces the
> following error:
>
> E_US0834 line 1, Table 'iipermits' owned by '$ingres' does not contain
> column 'table_name'.
>
> My thought: the view iipermits in a 2.6 installation has got a column
> named table_name and on the 6.4 it does not.
>
> But when I looked at the iipermits on the 2.6 installation I could (and
> still can't) not find a column named table_name.
>
> The complete error:
> INGRES COPYDB Copyright 2003 Computer Associates Intl, Inc.^M
> Unload directory is '/var/opt/monica/data/sita_utr_0605'.
> Reload directory is '/var/opt/monica/data/sita_utr_0605'.
> There is one table owned by user 'sita'.
> E_US0834 line 1, Table 'iipermits' owned by '$ingres' does not contain
> column 'table_name'.
> (Wed Jun 15 11:35:38 2005)
>
> So after the tables is quits.
> Views and procedures wil not be copied out.
>
> I am glad that the database on which I do the copyout does not have
> views or proceudres.
>
> I just want to understand it and want to know to prevent possible
> future errors.
>
> thanks!
>
> Erwin
>
We saw this error when running the copydb command on a 2.6 installation
and the target database was on 6.4. We ignored it as a difference
between 2.6 and 6.4 and didn't have any problems.

Dennis

On 15 Jun 2005 23:58:34 -0700, eteunisse <eteunisse@gmail.com> wrote:
> I did a remote copydb from a Linux 2.6 installation on a 6.4 database.
> The COPYDB (internally) does a sql-statement which produces the
> following error:
>
> E_US0834 line 1, Table 'iipermits' owned by '$ingres' does not contain
> column 'table_name'.
>
> My thought: the view iipermits in a 2.6 installation has got a column
> named table_name and on the 6.4 it does not.
>
> But when I looked at the iipermits on the 2.6 installation I could (and
> still can't) not find a column named table_name.
>
> The complete error:
> INGRES COPYDB Copyright 2003 Computer Associates Intl, Inc.^M
> Unload directory is '/var/opt/monica/data/sita_utr_0605'.
> Reload directory is '/var/opt/monica/data/sita_utr_0605'.
> There is one table owned by user 'sita'.
> E_US0834 line 1, Table 'iipermits' owned by '$ingres' does not contain
> column 'table_name'.
> (Wed Jun 15 11:35:38 2005)
>
> So after the tables is quits.
> Views and procedures wil not be copied out.
>
> I am glad that the database on which I do the copyout does not have
> views or proceudres.
>
> I just want to understand it and want to know to prevent possible
> future errors.
>
> thanks!
>

It's a bug. If you run with printqry you'll find it generates this SQL

select p.object_name, p.object_owner, p.permit_number,
p.text_sequence, p.text_segment
from iipermits p, iitables t
where
(p.object_owner='ingres' or ''='ingres' )
and p.object_type='T'
and p.object_name='pm'
and t.table_name=p.table_name
and t.table_owner=p.object_owner
and t.table_type='T'
order by p.object_owner, p.object_name, p.permit_number, p.text_sequence

Which is incorrect. The join should be "t.table_name=p.object_name"

AFAICS this have never been spotted before - I found the offending SQL
in the r3 source code (front/misc/xferdb/xfpermit.sc). It only gets
generated if you're running against a 6.4 or earlier database and have
specified a list of tables. I guess it's never been spotted before
because most people running a current copydb against a prior version
would probably be doing an upgrade and therefore doing the entire
database.

HTH
--
Paul Mason