importing dblink problem

[Doug Cowles]

I do a small import regularly.. and every time, a series of packages and

procedures refuse to compile because of the absence of a database link.
I assumed it was because the database link was imported after the
packages,
so they only would have to be recompiled - but even if I create the link

first (and it is definitely valid), this part of the import (the last
part), always fails.
In addition, the packages don't import and sit with an invalid status,
they just
don't come in.

Any suggestions?

dco...@i84.net or
dco...@bigfoot.com

[Marcus N Hofer]

what errmessage do you retrieve if you try to recompile one of these
packages with
'alter package XXXX compile;' ?

maybe the code uses synonyms using some other dblink that is no longer
valid.
the errmessage above should return the name of the offending dblink.

--marcus

Doug Cowles schrieb in Nachricht <360EC359...@i84.net>...

[Henry Poras]

I ran into a similar problem a few months ago. I didn't have the time to
fully track down the cause (and solution), but I had some guesses (which can
be tested). Going back to my notes and the recesses of my memory, this is
what I found.

I did a full import and got ORA-4054 'Database link does not exist'. At first
I thought what you thought, that it was a problem with the order of the
import. That the procedures and packages were imported before the db links. I
checked the logs, and the links were created first. I also redid the import
with the db links existing and got the same error. When I ran the create
procedure scripts from SQL*Plus, the same thing happened.

It turned out, as best as I can remember, that these problems only existed
with private db links. Also, when the create procedure statement was run as
the owner of the procedure and link it worked. The problem was running CREATE
PROCEDURE schema.procedure where it contained a private link. Apparantly even
though the import utility changes to each schema (sort of) when importing its
objects, this doesn't happen recursively to the depth of the private dblink
within the procedures. This seems to be the root of the problem. This could
be tested by using some simple test procedures. Also, doing the import by
logging in as the object owner might solve the problem.

I hope this helps.

Henry