I’m currently working with an application on Oracle Forms & Reports 6i with a 10g database that has packages, this application has Over 900 .fmb/fmx files and Over 700 .rep/rdf files. I have copied the application to another computer, and now it’s giving me these errors on most of the forms:
FRM-40735: XXXXXX trigger raised unhandled exception ORA-04062.
Or
ORA-04062 signature of package BLABLA has been changed
I figured out that i have to recompile the form for it to work, and it did, but as i said i have many forms and it’s time consuming to recompile all the forms and packages every time i change the computer.
Where the problem comes from? and what can i do to solve this?
asked Aug 10, 2017 at 10:02
The ORA-04062 error occurs when the spec of a database package used by the Form has changed. Moving the Forms from one client to another shouldn’t cause this unless the target database has changed too.
Part of the problem is that you’re working with a really version of Forms. But I guess upgrading is not an option (because you need the client/server version).
Do you need to compile all the Forms? How many Forms use the affected package? If you must compile a lot of Forms the easiest thing to do is write a .bat script to compile them.
answered Aug 10, 2017 at 17:28
APCAPC
144k19 gold badges170 silver badges281 bronze badges
This is also an issue with PL/SQL when a remote database session calls a PL/SQL function, procedure or package via database link to the database server, and the code on the server has a newer timestamp than the last time the client called it.
The remote_dependencies_mode parameter defaults to checking the timestamp of the stored code. It can be changed to signature to avoid the ORA-4062 error.
This is probably not something you would change at an instance level.
What I have used in PL/SQL:
execute immediate q'[alter session set remote_dependencies_mode = 'SIGNATURE']';
This may or may not work with Forms.
If all else fails, it could be set in a session via a logon trigger if this is an issue you regularly have to deal with.
answered Dec 6, 2022 at 20:49
Форум программистов Vingrad
| Модераторы: LSD |
Поиск: |
  
|
 ORA-04062, timestamp of package has been changed |
Опции темы |
| batigoal |
|
||
Нелетучий Мыш Профиль
Репутация: 2
|
Такая проблема. Есть пакет в моей схеме. Процедура из этого пакета (назовем её локальной) вызывает удаленную процедуру (тоже пакетированную) через db-link. Разумеется, я сразу полез в документацию.
Но перекомпиляция не помогла. Не помогло даже удаление и создание пакета заново. Совсем отчаялся, не понимаю, в чем дело. Готов валить на Оракловый баг. Дайте совет, если есть идеи. ——————— «Чтобы правильно задать вопрос, нужно знать большую часть ответа» (Р. Шекли) |
||
|
|||
Загрузка …
| batigoal |
|
||
|
Нелетучий Мыш Профиль
Репутация: 2
|
В общем, дело сильно смахивает на баг. Обойти сумели, сменив настройку базы REMOTE_DEPENDENCIES_MODE на SIGNATURE (было TIMESTAMP). Но это, конечно, workaround. ——————— «Чтобы правильно задать вопрос, нужно знать большую часть ответа» (Р. Шекли) |
||
|
|||
| Sqlninja |
|
||
Опытный Профиль
Репутация: 13
|
Да не, это кажется не баг… Среду опиши подробнее — это процедурная репликация настроена или единичный вызов процедуры через db_link? ——————— It’s better to burn out than to fade away. |
||
|
|||
| batigoal |
|
||
|
Нелетучий Мыш Профиль
Репутация: 2
|
Я не очень понимаю, что такое «процедурная репликация», но это вызов через dblink. Добавлено @ 10:12 ——————— «Чтобы правильно задать вопрос, нужно знать большую часть ответа» (Р. Шекли) |
||
|
|||
| Sqlninja |
|
||
|
Опытный Профиль
Репутация: 13
|
А можно версии серверов? ——————— It’s better to burn out than to fade away. |
||
|
|||
| batigoal |
|
||
|
Нелетучий Мыш Профиль
Репутация: 2
|
9.2.0.8.0, обе. ——————— «Чтобы правильно задать вопрос, нужно знать большую часть ответа» (Р. Шекли) |
||
|
|||
| Sqlninja |
|
||
|
Опытный Профиль
Репутация: 13
|
ну и наверное последний вопрос (перед тем как сказать что хрен его знает в чем дело) — а в каком порядке делалась перекомпиляция? ——————— It’s better to burn out than to fade away. |
||
|
|||
| batigoal |
|
||
|
Нелетучий Мыш Профиль
Репутация: 2
|
Сначала удаленная процедура, потом локальная. Но наоборот я тоже уже пробовал ——————— «Чтобы правильно задать вопрос, нужно знать большую часть ответа» (Р. Шекли) |
||
|
|||
)
| batigoal |
|
||
|
Нелетучий Мыш Профиль
Репутация: 2
|
Одна гипотеза возникла — между базами была открытая сессия, и timestamp пакета был в ней «запомнен». ——————— «Чтобы правильно задать вопрос, нужно знать большую часть ответа» (Р. Шекли) |
||
|
|||
|
|
| Правила форума «Oracle» | |
 |
Данный раздел предназначен для обсуждения проблем с Oracle Database, другие продукты Oracle здесь не обсуждаются. Просьба при создании темы, придерживаться следующих правил:
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Zloxa, LSD. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) |
| 0 Пользователей: |
| « Предыдущая тема | Oracle | Следующая тема » |
- Env
- ORA-04062 error
- Reason
- Re-Install Database
- recreate cdb/pdb use as below command.
- Reference
DBCA fails with the following error.
ERROR=ORA-04062: signature of package "SYS.DBMS_BACKUP_RESTORE" has been changed
Env
SQL> select banner from v$version;
BANNER
----------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
SQL> select banner_full from v$version;
BANNER_FULL
-----------------------------------------------------------------------------------------
Oracle Database 19c Enterprise Edition Release 19.0.0.0.0 - Production
Version 19.3.0.0.0
SQL> !cat /etc/redhat-release
Red Hat Enterprise Linux release 8.4 (Ootpa)
SQL> !uname -r
5.4.17-2102.201.3.el8uek.x86_64
SQL>
ORA-04062 error
DBCA fails with Error: ORA-04062: signature of package “SYS.DBMS_BACKUP_RESTORE” has been changed
[oracle@ol8-19c dbhome_1]$ cat /u01/app/oracle/cfgtoollogs/dbca/cdb2/cdb21.log
[ 2022-01-21 10:00:18.615 CST ] [WARNING] [DBT-06208] The 'SYS' password entered does not conform to the Oracle recommended standards.
[ 2022-01-21 10:00:18.615 CST ] [WARNING] [DBT-06208] The 'PDBADMIN' password entered does not conform to the Oracle recommended standards.
[ 2022-01-21 10:00:20.143 CST ] Prepare for db operation
DBCA_PROGRESS : 8%
[ 2022-01-21 10:00:20.313 CST ] Copying database files
DBCA_PROGRESS : 31%
[ 2022-01-21 10:02:19.050 CST ] Creating and starting Oracle instance
DBCA_PROGRESS : 32%
DBCA_PROGRESS : 36%
DBCA_PROGRESS : 46%
DBCA_PROGRESS : 100%
[ 2022-01-21 10:03:07.024 CST ] [FATAL] Error while restoring PDB backup piece
DBCA_PROGRESS : 31%
DBCA_PROGRESS : 8%
DBCA_PROGRESS : 0%
[oracle@ol8-19c dbhome_1]$
The trace log in /u01/app/oracle/cfgtoollogs/dbca are as below.
[Thread-68] [ 2022-01-21 10:43:50.874 CST ] [RMANUtil$RMANUtilErrorListener.handleError:1386] ERROR=channel ORA_DISK_1: SID=29 device type=DISK
[Thread-68] [ 2022-01-21 10:43:50.874 CST ] [RMANUtil$RMANUtilErrorListener.handleError:1386] ERROR=RMAN-00571: ===================================================
========
[Thread-68] [ 2022-01-21 10:43:50.874 CST ] [RMANUtil$RMANUtilErrorListener.handleError:1386] ERROR=RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =======
========
[Thread-68] [ 2022-01-21 10:43:50.874 CST ] [RMANUtil$RMANUtilErrorListener.handleError:1386] ERROR=RMAN-00571: ===================================================
========
[Thread-68] [ 2022-01-21 10:43:50.874 CST ] [RMANUtil$RMANUtilErrorListener.handleError:1386] ERROR=RMAN-03002: failure of restore command at 01/21/2022 10:43:50
[Thread-68] [ 2022-01-21 10:43:50.874 CST ] [RMANUtil$RMANUtilErrorListener.handleError:1386] ERROR=ORA-04062: signature of package "SYS.DBMS_BACKUP_RESTORE" has b
een changed
[Thread-68] [ 2022-01-21 10:43:50.874 CST ] [RMANUtil$RMANUtilErrorListener.handleError:1386] ERROR=RMAN>
Reason
ORA-04062: signature of package “SYS.DBMS_BACKUP_RESTORE” has been changed when using DBCA on 19c (Doc ID 2741745.1)
Note: The cause is known, But seems there is a conflict between the rman version packages that is coming from the patch vs rman version packages used by DBCA Template.
1-. Create a fresh Installed for 19.03.00.00 or rollback 19C PSU
2-. Run DBCA to create CDB
3-. Re-apply 19C RU and run datapatch
Once the Database is created and/or upgraded, if still receiving
SYS.DBMS_BACKUP_RESTORE version is not current
Then follow steps from: 2741760.1 - PL/SQL package SYS.DBMS_BACKUP_RESTORE version is not current
Recompile the RMAN packages and procedures by connecting to the target database as SYSDBA and execute:
$ sqlplus / as sysdba
SQL> @$ORACLE_HOME/rdbms/admin/dbmsrman.sql
SQL> @$ORACLE_HOME/rdbms/admin/dbmsbkrs.sql
SQL> @$ORACLE_HOME/rdbms/admin/prvtrmns.plb
SQL> @$ORACLE_HOME/rdbms/admin/prvtbkrs.plb
Note: The cause is known, But seems there is a conflict between the rman version packages that is coming from the patch vs rman version packages used by DBCA Template.
This note only applied when creating a Database using DBCA and Patch has been applied before database as been created.
Re-Install Database
ReInstall Database.
There is a conflict between the rman version packages that is coming from the patch vs rman version packages used by DBCA Template.
[oracle@ol8-19c software]$ ls -tlr LINUX.X64_193000_db_home.zip
-rwxrwx--- 1 root vboxsf 3059705302 Jul 7 2021 LINUX.X64_193000_db_home.zip
[oracle@ol8-19c software]$ pwd
/software
[oracle@ol8-19c software]$ cd $ORACLE_HOME
[oracle@ol8-19c dbhome_2]$ cd ../dbhome_1/
[oracle@ol8-19c dbhome_1]$ unzip -oq /software/LINUX.X64_193000_db_home.zip
[oracle@ol8-19c dbhome_1]$ export CV_ASSUME_DISTID=OEL7.6
[oracle@ol8-19c dbhome_1]$ pwd
/u01/app/oracle/product/19.0.0/dbhome_1
[oracle@ol8-19c dbhome_1]$ export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
[oracle@ol8-19c dbhome_1]$ ./runInstaller -ignorePrereq -waitforcompletion -silent \
> -responseFile ${ORACLE_HOME}/install/response/db_install.rsp \
> oracle.install.option=INSTALL_DB_SWONLY \
> ORACLE_HOSTNAME=${ORACLE_HOSTNAME} \
> UNIX_GROUP_NAME=oinstall \
> INVENTORY_LOCATION=${ORA_INVENTORY} \
> SELECTED_LANGUAGES=en,en_GB \
> ORACLE_HOME=${ORACLE_HOME} \
> ORACLE_BASE=${ORACLE_BASE} \
> oracle.install.db.InstallEdition=EE \
> oracle.install.db.OSDBA_GROUP=dba \
> oracle.install.db.OSBACKUPDBA_GROUP=dba \
> oracle.install.db.OSDGDBA_GROUP=dba \
> oracle.install.db.OSKMDBA_GROUP=dba \
> oracle.install.db.OSRACDBA_GROUP=dba \
> SECURITY_UPDATES_VIA_MYORACLESUPPORT=false \
> DECLINE_SECURITY_UPDATES=true
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = (unset),
LC_ALL = (unset),
LC_CTYPE = "UTF-8",
LANG = "en_US.UTF-8"
are supported and installed on your system.
perl: warning: Falling back to a fallback locale ("en_US.UTF-8").
Launching Oracle Database Setup Wizard...
[WARNING] [INS-13014] Target environment does not meet some optional requirements.
CAUSE: Some of the optional prerequisites are not met. See logs for details. /u01/app/oraInventory/logs/InstallActions2022-01-21_11-54-20AM/installActions2022-01-21_11-54-20AM.log
ACTION: Identify the list of failed prerequisite checks from the log: /u01/app/oraInventory/logs/InstallActions2022-01-21_11-54-20AM/installActions2022-01-21_11-54-20AM.log. Then either from the log file or from installation manual find the appropriate configuration to meet the prerequisites and fix it manually.
The response file for this session can be found at:
/u01/app/oracle/product/19.0.0/dbhome_1/install/response/db_2022-01-21_11-54-20AM.rsp
You can find the log of this install session at:
/u01/app/oraInventory/logs/InstallActions2022-01-21_11-54-20AM/installActions2022-01-21_11-54-20AM.log
As a root user, execute the following script(s):
1. /u01/app/oracle/product/19.0.0/dbhome_1/root.sh
Execute /u01/app/oracle/product/19.0.0/dbhome_1/root.sh on the following nodes:
[ol8-19c]
[oracle@ol8-19c dbhome_1]$ su -
Password:
[root@ol8-19c ~]# /u01/app/oraInventory/orainstRoot.sh
-bash: /u01/app/oraInventory/orainstRoot.sh: No such file or directory
[root@ol8-19c ~]# /u01/app/oracle/product/19.0.0/dbhome_1/root.sh
Check /u01/app/oracle/product/19.0.0/dbhome_1/install/root_ol8-19c_2022-01-21_11-56-47-912597304.log for the output of root script
[root@ol8-19c ~]# cat /u01/app/oracle/product/19.0.0/dbhome_1/install/root_ol8-19c_2022-01-21_11-56-47-912597304.log
Performing root user operation.
The following environment variables are set as:
ORACLE_OWNER= oracle
ORACLE_HOME= /u01/app/oracle/product/19.0.0/dbhome_1
Copying dbhome to /usr/local/bin ...
Copying oraenv to /usr/local/bin ...
Copying coraenv to /usr/local/bin ...
Entries will be added to the /etc/oratab file as needed by
Database Configuration Assistant when a database is created
Finished running generic part of root script.
Now product-specific root actions will be performed.
Oracle Trace File Analyzer (TFA) is available at : /u01/app/oracle/product/19.0.0/dbhome_1/bin/tfactl
[root@ol8-19c ~]# exit
logout
[oracle@ol8-19c dbhome_1]$
recreate cdb/pdb use as below command.
dbca create cdb as silent mode.
dbca -silent -createDatabase -templateName General_Purpose.dbc -createAsContainerDatabase true -numberOfPDBs 1 -pdbName orclpdb -gdbname oradb.example.com -sid oradb -sysPassword oracle -systemPassword oracle -pdbAdminPassword oracle -characterSet AL32UTF8 -memoryPercentage 50 -responseFile NO_VALUE -emConfiguration LOCAL
43% complete
46% complete
Completing Database Creation
51% complete
53% complete
54% complete
Creating Pluggable Databases
58% complete
77% complete
Executing Post Configuration Actions
100% complete
Database creation complete. For details check the logfiles at:
/u01/app/oracle/cfgtoollogs/dbca/oradb.
Database Information:
Global Database Name:oradb.example.com
System Identifier(SID):oradb
Look at the log file "/u01/app/oracle/cfgtoollogs/dbca/oradb/oradb0.log" for further details.
[oracle@ol8-19c dbhome_1]$ ps -ef | grep smon
oracle 14029 1 0 12:10 ? 00:00:00 ora_smon_oradb
oracle 14869 2637 0 13:08 pts/1 00:00:00 grep --color=auto smon
[oracle@ol8-19c dbhome_1]$
Reference
dbca sample for creating cdb/pdb.
dbca -silent -createDatabase \
-templateName General_Purpose.dbc \
-gdbname cdb3 -sid cdb3 -responseFile NO_VALUE \
-characterSet AL32UTF8 \
-sysPassword Oracle123 \
-systemPassword Oracle123 \
-createAsContainerDatabase true \
-numberOfPDBs 1 \
-pdbName pdb1 \
-pdbAdminPassword Oracle123 \
-databaseType MULTIPURPOSE \
-memoryMgmtType auto_sga \
-totalMemory 2000 \
-storageType FS \
-datafileDestination "/u02/oradata/" \
-redoLogFileSize 50 \
-emConfiguration NONE \
-ignorePreReqs
Error in DBCA (create a CDB) — “Error while restoring PDB backup piece” is met during the “Creating and starting Oracle Instance” step (Doc ID 2831203.1)
CAUSE
Upon running "opatch lsinventory -detail", it was found that opatch lsinventory is not running. When checking the physical path of file, the inventory file was not present.
SOLUTION
Recreate the central inventory and registered the Oracle database home. Then run DBCA once again.
This should resolve this issue.
Steps To Recreate Central Inventory(oraInventory) In RDBMS Homes (Doc ID 556834.1)
Have a good work&life! 2022/01 via LinHong
Similar Posts
ORA-4062 Explained (for Client and Server PL/SQL) [ID 73506.1]
Applies to:
PL/SQL — Version: 7.3.4.5 to 11.1.0.7 — Release: to 11.1
Information in this document applies to any platform.
Checked for relevance on 25-Feb-2010
Purpose
This article contains information about the ORA-4062 error which can occur when using client-side PL/SQL (Oracle Forms, Reports) or server-side PL/SQL across a database link.
Scope and Application
This article is intended for any level of user seeking an explanation of the error code.
ORA-4062 Explained (for Client and Server PL/SQL)
Background
ORA-4062 indicates that ‘TIMESTAMP / SIGNATURE of NAME has been changed’.
When a local piece of PL/SQL references a remote package, function, or procedure, the local PL/SQL engine needs to know if the reference is still valid, or, if the remote procedure has changed.
The locally compiled PL/SQL code is ‘dependent’ on the remote code. The following two models can be used in Oracle to track this dependency:
TIMESTAMPS
-OR-
SIGNATURES
The method used is determined by the server initialization <Parameter:REMOTE_DEPENDENCIES_MODE>. This can be set at the instance (initSID.ora) or session (ALTER SESSION) level.
Additionally, we allow ‘runtime binding’ which allows client PLSQL to delay the actual binding up of a reference to a SCHEMA.OBJECT.
Timestamp
If the dependency mode is set to TIMESTAMP, the local PL/SQL block can only execute the remote PL/SQL block if the timestamp on the remote procedure matches the timestamp stored in the locally compiled PL/SQL block. If the timestamps do not match, the local PL/SQL must be recompiled.
Signature
If the dependency mode is set to SIGNATURE, the local PL/SQL block can still execute the remote PL/SQL block if its ‘signature’ is the same, even if the timestamp has changed.
The ‘signature’ basically means the interface (procedure name, parameter types or modes) is the same, even if the underlying implementation has changed.
A description of the factors that the SIGNATURE depends on can be found in Chapter 7 of the Oracle Application Developers Guide in the section on Remote Dependencies (up to Version 10.1) or in Chapter 6 of the Oracle Database Concepts guide (Version 10.2 onwards). It is important to read this section because a few disadvantages exist to using a SIGNATURE dependency model.
The main disadvantage is that a few changes to a stored package / procedure require manual recompilation of the calling PL/SQL. For example, if an overloaded version of an existing procedure is added, then the caller still uses the original version until the caller is recompiled.
ORA-4062
This error is reported if the local PL/SQL block cannot call the remote procedure, since the timestamp or signature has changed on the remote end. A local recompilation may be required to make the call.
In the case of server to server calls, the local PL/SQL block is implicitly recompiled on the next call after an ORA-4062 error. In the case of client tools to server calls, the client Form or Report usually needs to be recompiled explicitly.
Recommendation
Oracle recommends that <Parameter:REMOTE_DEPENDENCIES_MODE> is set to SIGNATURE when client-side PL/SQL tools are used OR when server-side PL/SQL calls are used across database links. This reduces the chances of the ORA-4062 errors and the need for unnecessary recompilations, but note the restrictions discussed in the Documentation as mentioned above.
Client tools, such as Developer, attempt to use SIGNATURE mode by issuing ‘ALTER SESSION’ statements. Therefore, the init.ora parameter setting is over-ridden for these products (provided users have the ‘ALTER SESSION’ privilege).
Known Issues
Provided that REMOTE_DEPENDENCIES_MODE is set correctly, ORA-4062 errors should only be signalled if the signature of the procedure changes.
For example, if the remote procedure contains a definition MYPROC( A NUMBER ),and this is changed to MYPROC( A NUMBER, B NUMBER ), the signature has changed. Therefore, it is expected behaviour that any PL/SQL calling MYPROC must be recompiled.
Many Oracle tools which include a client-side PL/SQL engine issue an
‘ALTER SESSION SET REMOTE_DEPENDENCIES_MODE=SIGNATURE’
statement to set the SIGNATURE dependency model. Errors from issuing this statement may be silently ignored. For example, if a user does not have the ‘ALTER SESSION’ privilege, then the REMOTE_DEPENDENCIES_MODE is left at the default mode (taken from the init.ora parameter setting).
Bug 5249142 ORA-04062: signature of package «SYS.UTL_RAW» has been changed
Additional Notes
If the parameters to a procedure use %TYPE or %ROWTYPE, then a change to the table on which the %TYPE or %ROWTYPE is based upon can change the signature of the procedure.
If the signature changes, an ORA-4062 error is correctly signaled. For client PL/SQL objects, changes to a signature require the client form or report to be recompiled. This is correct behaviour.
Conclusion
If, after reviewing the above steps, you believe you have a scenario where an ORA-4062 is being incorrectly signalled, then it is important to describe each step that leads to the error. Oracle Support Services requires a small test case to establish validity for the error.
>
ORA-4062 Explained (for Client and Server PL/SQL)
Background
ORA-4062 indicates that ‘TIMESTAMP / SIGNATURE of NAME has been changed’.
When a local piece of PL/SQL references a remote package, function, or procedure, the local PL/SQL engine needs to know if the reference is still valid, or, if the remote procedure has changed.
The locally compiled PL/SQL code is ‘dependent’ on the remote code. The following two models can be used in Oracle to track this dependency:
TIMESTAMPS
-OR-
SIGNATURES
The method used is determined by the server initialization . This can be set at the instance (initSID.ora) or session (ALTER SESSION) level.
Additionally, we allow ‘runtime binding’ which allows client PLSQL to delay the actual binding up of a reference to a SCHEMA.OBJECT.
Timestamp
If the dependency mode is set to TIMESTAMP, the local PL/SQL block can only execute the remote PL/SQL block if the timestamp on the remote procedure matches the timestamp stored in the locally compiled PL/SQL block. If the timestamps do not match, the local PL/SQL must be recompiled.
Signature
If the dependency mode is set to SIGNATURE, the local PL/SQL block can still execute the remote PL/SQL block if its ‘signature’ is the same, even if the timestamp has changed.
The ‘signature’ basically means the interface (procedure name, parameter types or modes) is the same, even if the underlying implementation has changed.
A description of the factors that the SIGNATURE depends on can be found in Chapter 7 of the Oracle Application Developers Guide in the section on Remote Dependencies (up to Version 10.1) or in Chapter 6 of the Oracle Database Concepts guide (Version 10.2 onwards). It is important to read this section because a few disadvantages exist to using a SIGNATURE dependency model.
The main disadvantage is that a few changes to a stored package / procedure require manual recompilation of the calling PL/SQL. For example, if an overloaded version of an existing procedure is added, then the caller still uses the original version until the caller is recompiled.
ORA-4062
This error is reported if the local PL/SQL block cannot call the remote procedure, since the timestamp or signature has changed on the remote end. A local recompilation may be required to make the call.
In the case of server to server calls, the local PL/SQL block is implicitly recompiled on the next call after an ORA-4062 error. In the case of client tools to server calls, the client Form or Report usually needs to be recompiled explicitly.
Recommendation
Oracle recommends that is set to SIGNATURE when client-side PL/SQL tools are used OR when server-side PL/SQL calls are used across database links. This reduces the chances of the ORA-4062 errors and the need for unnecessary recompilations, but note the restrictions discussed in the Documentation as mentioned above.
Client tools, such as Developer, attempt to use SIGNATURE mode by issuing ‘ALTER SESSION’ statements. Therefore, the init.ora parameter setting is over-ridden for these products (provided users have the ‘ALTER SESSION’ privilege).
Known Issues
Provided that REMOTE_DEPENDENCIES_MODE is set correctly, ORA-4062 errors should only be signalled if the signature of the procedure changes.
For example, if the remote procedure contains a definition MYPROC( A NUMBER ),and this is changed to MYPROC( A NUMBER, B NUMBER ), the signature has changed. Therefore, it is expected behaviour that any PL/SQL calling MYPROC must be recompiled.
Many Oracle tools which include a client-side PL/SQL engine issue an
‘ALTER SESSION SET REMOTE_DEPENDENCIES_MODE=SIGNATURE’
statement to set the SIGNATURE dependency model. Errors from issuing this statement may be silently ignored. For example, if a user does not have the ‘ALTER SESSION’ privilege, then the REMOTE_DEPENDENCIES_MODE is left at the default mode (taken from the init.ora parameter setting).