Hi
We are running our apps in distributed database environment.
we r in the process of migrating our central DB from ver 9 to 10.1.2
and are facing problems while creating materialized views. Our remote
servers run 8.1.7 standard ver DB.
So when I tried to create MVs(40 MVs in all) from the remote server we
recd following error:
ORA-12018: following error encountered during code generation for ----
ORA-00942: table or view does not exist
ORA-02063: preceding line from ....

I found out that it was due to fast refresh option, and so attempted
refresh complete option. This way we could create 36 MVs. The
remaining 7 continue to throw the same errors.
I attempted to query the master tables of failed MVs using db_link but
received
ora-2019.
We never had any problem with 9i. We infact have 60 remote servers
with 8i connecting to 9i database and never faced this problem.
Is this some bug with 10g. REQUIRE your expertise in sorting this
problem.
thks
clement

On Tue, 16 Oct 2007 19:54:00 -0000, clement rajappa
<clement.rajappa (AT) gmail (DOT) com> wrote:

10g only communicates with 8.1.7.*4*

--
Sybrand Bakker
Senior Oracle DBA

On 16 Oct, 20:54, clement rajappa <clement.raja... (AT) gmail (DOT) com> wrote:
Have a look at Metalink Note 207303.1

Oracle no longer support any interoperability between 8.1.7 and 10. I
know this because our site pays for Extended Maintenance Support on
8.1.7, but we have discovered that support does not extend to
interoperability.

We replicate onto our 10.2.0.2 database from about 20 different sites.
The oldest being 8.1.6, which does work but is not supported. On 10.1
we did get a number of errors suggesting we could not communicate with
some 8.1 databases, but this is bug 3437884 which should be in the
10.1.0.3 patchset. It's definitely fixed when you get to 10.2.0.2.

The other issue we get is intermittent ORA-0600 [16606] errors when
fast refreshing from 8.1 databases. We replicate pretty frequently and
whenever I've investigated the errors from the alert log we have
usually fast refreshed again and captured all the data we need. I