SQL0181N on nickname for union-all-view

[_link98]

Problem: getting SQL0181N for queries on nicknames to remote
Union-All-View.
Can't see what I'm doing wrong yet, maybe someone has seen this before.

Environment: UDB ESE 8.1 + FIXPAK 9A, on Solaris 8.1, with 64-bit
instances.

I have a NICKNAME called REMOTE_DW.T_MYTABLE which points to a
"union-all-view".
Several other nicknames exist to regular-tables and regular views in
the remote database.

The "union-all-view" is in a database in another instance on the same
hostname,
(the remote-database).

If I perform "select count(*) on REMOTE_DW.T_MYTABLE" then the result
is SQL0181N
(i.e. while connected as the instance-owner to the federated database
in which
there is a nickname for the union-all-view on the remote database).

The "union-all-view" has a partitioning-column of type DATE, if that's
important.

But if I perform that same query on the other database directly (i.e.
not using the nickname, using a direct connection to the remote
database),
then the query gives the correct count of rows.

Additionally, if I perform simple queries on nicknames that are NOT to
"union-all-view"
(i.e. they point to reguar tables, or regular views) then these queries
also work OK
on the federated database.

The symptom is specific to queries on nicknames for "union-all-views".

For both the local database, and the "remote" database, the
authorization-id is that of
the respective instance-owners. There is a "user-mapping" for the
local-instance-owner
to the remote-instance-owner.

[Rhino]

<_l*****@yahoo.com> wrote in message
news:11********************@g44g2000cwa.googlegrou ps.com...

Problem: getting SQL0181N for queries on nicknames to remote
Union-All-View.
Can't see what I'm doing wrong yet, maybe someone has seen this before.

Environment: UDB ESE 8.1 + FIXPAK 9A, on Solaris 8.1, with 64-bit
instances.

I have a NICKNAME called REMOTE_DW.T_MYTABLE which points to a
"union-all-view".
Several other nicknames exist to regular-tables and regular views in
the remote database.

The "union-all-view" is in a database in another instance on the same
hostname,
(the remote-database).

If I perform "select count(*) on REMOTE_DW.T_MYTABLE" then the result
is SQL0181N
(i.e. while connected as the instance-owner to the federated database
in which
there is a nickname for the union-all-view on the remote database).

The "union-all-view" has a partitioning-column of type DATE, if that's
important.

But if I perform that same query on the other database directly (i.e.
not using the nickname, using a direct connection to the remote
database),
then the query gives the correct count of rows.

Additionally, if I perform simple queries on nicknames that are NOT to
"union-all-view"
(i.e. they point to reguar tables, or regular views) then these queries
also work OK
on the federated database.

The symptom is specific to queries on nicknames for "union-all-views".

For both the local database, and the "remote" database, the
authorization-id is that of
the respective instance-owners. There is a "user-mapping" for the
local-instance-owner
to the remote-instance-owner.

SQL0181N is a very common error and is documented in the
Reference/Messages/SQL portion of the Information Center. It simply
indicates that some portion of a date is out of range. For instance, if you
construct a date that has a month of 15 or a year that is outside of the
range 1 to 9999, you'll get an SQL0181N. Look at the expressions that you
are creating based on the values in your Date column and I fully expect that
you'll find a bad date expression causing your error.

I don't think the nickname or the fact that you are using UNION ALL is a
real factor in the problem, just red herrings tripping you up.

Rhino

[_link98]

Hmmm, although I know well what the SQL0181N code means, it's just a
bit strange
that "select count(*) from <nickname_schema>.<union-all-view>"
gives the SQL0181N, even when all target tables of the view are empty,
and
there's no dates specified on the query.

[Rhino]

<_l*****@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

Hmmm, although I know well what the SQL0181N code means, it's just a
bit strange
that "select count(*) from <nickname_schema>.<union-all-view>"
gives the SQL0181N, even when all target tables of the view are empty,
and
there's no dates specified on the query.

Sorry, I didn't read your question as carefully as I should have. I agree
that the full set of symptoms makes my original suggestion a bit improbable.

But I'm at a loss to suggest any good explanations for why you're seeing
this behaviour.

As for resolving the problem, I suggest that you look through the APAR lists
and see if there are any recent fixes involving SQL0181N; install the
appropriate fixpack if you find such an APAR. If you can't find any fixpack
that resolves the problem, call IBM Support for some help in tracking this
down.

Rhino

[mike_li]

I have this problem before. Just drop the nickname, and create a new
one. Try it.

[Serge Rielau]

Rhino wrote:

<_l*****@yahoo.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

Hmmm, although I know well what the SQL0181N code means, it's just a
bit strange
that "select count(*) from <nickname_schema>.<union-all-view>"
gives the SQL0181N, even when all target tables of the view are empty,
and
there's no dates specified on the query.

Sorry, I didn't read your question as carefully as I should have. I agree
that the full set of symptoms makes my original suggestion a bit improbable.

But I'm at a loss to suggest any good explanations for why you're seeing
this behaviour.

As for resolving the problem, I suggest that you look through the APAR lists
and see if there are any recent fixes involving SQL0181N; install the
appropriate fixpack if you find such an APAR. If you can't find any fixpack
that resolves the problem, call IBM Support for some help in tracking this
down.

Rhino

I agree, support.
Cheers
Serge

--
Serge Rielau
DB2 SQL Compiler Development
IBM Toronto Lab

[_link98]

Thanks mike_li, just dropping and recreating the nickname was not
enough to fix it.
Instead, I studied the column check constraint on the target tables of
the union-all-view.
Could not see any problem, but as a trial I dropped and recreated the
check-constraints
on the partitioning column, for each union-all-view, and that worked
(did not even need
to disconnect from the federated database or remake nicknames).
There's a weirdness in there somewhere but I need to have a recreatable
scenario
before opening a PMR , so I'll work on that later.