This content has been marked as final. Show 22 replies
Jamie CC wrote:What about running it via a PL/SQL anonymous block, e.g.
SQL> select * from dual@unanet_unanet;
This will tell us if the problem is with access to the remote object PROJECT, or with using this db link in general in PL/SQL code.
declare s varchar2(100); begin select dummy into s from dual@unanet_unanet; end;
I have come across some forums that mention incompatibilities with the character sets and my old db and new db have different ones.
So I am recreating and reloading the new db with the same character set as the old db and will see what that does.
Anyone else have any insight as to what this could be please feel free to comment.
sb92075 wrote:The anonymous PL/SQL block test the OP did on the remote project table failed - so one step at a time in trying to isolate it.. PL/SQL seems to factor. And before looking at named procedures, the fact that it fails with anonymous code and not SQL (from the same session) with the exceptions it did, is rather strange.
Anonymous PL/SQL behaves differently than NAMED PL/SQL procedures.
Well database recreated with same character set as old db and data reloaded and I am still seeing same error.
Works in the 126.96.36.199 db on Solaris but won't compile in the 188.8.131.52 db on HP-UX.
Still not sure why the dblinks needed to be recreated without the .world extension on the new db but not on the old one...
Both dbs have global_names set to false and db_domain isn't set.
I came across this problem today.
We are on a 184.108.40.206 db trying to reference remote objects on a 10.2.0.4 db from PL/SQL.
Our DB link works with plain SQL.
But is does not work within PL/SQL code (anonymous nor named PL/SQL code) - we are getting the same error codes as you describe.
Did you ever find a solution on the problem ?
I you remember the metalink that you mention, pls post it.