Sie können diesen Effekt sehen, ob Sie Ihre current_schema
ändern. Wenn das Ihre Benutzer passt dann funktioniert es OK:
select user, sys_context('userenv', 'current_schema') as schema from dual;
USER SCHEMA
------------------------------ ------------------------------
USER_1 USER_1
create synonym syn_name for admin.procedure_name;
Synonym SYN_NAME created.
exec syn_name;
PL/SQL procedure successfully completed.
Aber wenn meine Sitzung eine andere current_schema
hat dann hat das Synonym mit meinem wirklichen Benutzernamen vorangestellt werden:
alter session set current_schema = user_2;
Session altered.
select user, sys_context('userenv', 'current_schema') as schema from dual;
USER SCHEMA
------------------------------ ------------------------------
USER_1 USER_2
select owner, synonym_name, table_owner, table_name
from all_synonyms where synonym_name = 'SYN_NAME';
OWNER SYNONYM_NAME TABLE_OWNER TABLE_NAME
------------------------------ ------------------------------ ------------------------------ ------------------------------
USER_1 SYN_NAME ADMIN PROCEDURE_NAME
exec syn_name;
ORA-06550: line 1, column 7:
PLS-00201: identifier 'SYN_NAME' must be declared
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
exec user_1.syn_name;
PL/SQL procedure successfully completed.
Sie nicht, dass Sie wissen vielleicht, Ändere dein aktuelles Schema; Es kann in einem Login-Trigger passieren, möglicherweise um Synonyme zu vermeiden. Sie können mit Ihrem aktuellen Schema prüfen:
select sys_context('userenv', 'current_schema') as schema from dual;
Wenn das tatsächlich zeigt Ihnen ADMIN
dann brauchen Sie gar nicht das Synonym und kann PROCEDURE_NAME
direkt rufen Sie einfach an, damit mit dem ADMIN
Schemanamen voranstellen müssen.
Lassen Sie mich das Alex testen, werde ich zurück so schnell wie möglich antworten .. – user1129209
Dank Alex, scheint, dass das Problem der Current_schema-Wert war. Vielen dank für Deine Hilfe. – user1129209