Finding File Versions in the Oracle Applications EBusiness Suite - Checking the $HEADER (文档 ID 858957.1)
In this Document
Goal
Solution
Diagnostic
Form
Versions
...
Form Versions: Help About
...
Form Versions: OS/UNIX
...
Form Versions: OS/UNIX Library
Java
Versions
...
Java Versions - Via Operating System:
...
Java Versions - Via SQL:
...
Java Versions - Via Application:
Report
Versions
PL/SQL
Packages
Definition
Files
Languages
Patch
Versions
...
Patch Versions - Oracle Applications
...
Patch Versions - Server/Database
APPLIES TO:
Oracle Inventory Management - Version:
11.5.10<max_ver> and later [Release: 11.5 and
later ]
Information in this document applies to any platform.
This
document includes all versions of Oracle EBS 11i and R12
GOAL
How to find file versions within Oracle Applicatins
SOLUTION
There are many ways to find file versions. This note will
attempt to list some of the most common and benefits of each method
listed.
Diagnostic
The quickest way to get versions is to find them all at once using a
diagnostic. This is also great for providing information to Oracle Support
to avoid providing one file version after another. The diagnostics often
query information from the patching logs (AD... tables like AD_FILE_VERSIONS)
described more below. The AppsCheck diagnostic is a great choice as it is
available within the application as a concurrent program. It runs for a series
of modules that the user selects and puts the information together in the same
file. The AppsCheck is actually called the ‘Diagnostics: Apps Check‘ concurrent
program. Read more in Note
156860.1 Order Management Suite Diagnostic Tool (omcheck.sql)
or Note
276207.1. Here is an example set of steps for submitting the
program:
Steps to submit the concurrent program using an Order Management responsibility:
- Navigation: Reports, Requests > Run Requests
- Submit a Single Request
- Name: Diagnostics: Apps Check
- Parameters:
Application 1: Oracle Inventory
Application 2: Oracle Order Management
Application 3: Oracle Shipping
Application 4: Oracle Warehouse Management
- Submit the request
Form Versions
... Form Versions: Help About
Often the quickest way to get a form version is in the Oracle
Application itself choosing Help > About. This works if the form is one that
users directly access (although this will not work for all form objects because
some are used behind the scenes as references). See the section "Current Form".
For example:
----------------------------------------
Current
Form
----------------------------------------
Form Application :
Inventory
Form Name : INVMWBIV
Form Path :
/global/oracle/visus25/apps/apps_st/appl/inv/12.0.0/forms/US/INVMWBIV.fmx
Form
Version : 12.0.79
Form Last Modified : $Date: 2010/04/07 02:43 $... Form Versions: OS/UNIX
Sometimes it is convenient to check the form version with a script
maybe because a technical person is checking the version, the form server is
down, the form in question is actually a sub-form, etc. In that case,
there are a few places to get the version but the form‘s compiled code that is
executing (.fmx) is often best to get this version. It is located in the product
top like $INV_TOP. It is sometimes also interesting to look at the raw source
code (.fmb) delivered on the environment in question. In that scenario,
one looks at $AU_TOP/forms. This is where the original source code is and shows
with .fmb extension. The .fmb file is generated into a .fmx file. For both of
these file types, as they are binary, you would need to use the strings command
then grep for the $Header information. For example, find the Material Workbench
(INVMWBIV.fmb) version with something like:
$
strings -a $INV_TOP/forms/US/INVMWBIV.fmx |grep ‘$Header‘
$Header: INVMWBIV.fmb 120.101.12000000.30 2008/07/17 07:07 ckrishna noship
... Form Versions: OS/UNIX Library
The form libraries are located in $AU_TOP/resource. The libraries
include 2 files: 1) the library file (.pll), and 2) the generated library file
(.plx). Both library and generated files are binary. The library file (.pll) can
be opened in Oracle Forms. Oracle Forms also is the tool to generate the
generated file (.plx). Often patches will mention the version of the source file
(.pld). The source file (.pld) is a text version of the library that can be
generated from Oracle Forms. The best way to get a library version is to use a
strings command on the library file in $AU_TOP/resource. The results show the
.pld version. For example:
$ strings -a $AU_TOP/resource/
INVTTMTX.pll |grep ‘$Header‘
FDRCSID(‘$Header: IGI_DOS.pld 120.5
2005/10/05 08:53:29 vkilambi ship $‘);
fdrcsid(‘$Header: INVTTMTX.pld
120.26.12010000.20 2010/07/27 10:17:00 mporecha ship $‘);
Java Versions
... Java Versions - Via Operating System:
The most common way to get java versions is at the operating system
level. The java versions of the Oracle Applications EBusiness Suite are stored
in $JAVA_TOP/oracle/apps. For example:
$
strings -a $JAVA_TOP/oracle/apps/inv/transaction/server/BaseTransaction.class |grep ‘$Header‘
$Header: BaseTransaction.java 115.235.115100.55 2008/12/19 14:09:15 rkatoori ship $
oracl
... Java Versions - Via SQL:
Some java code is also stored in the database. For these java files,
one can issue a SQL command to get the version. For example:
Sql>set serveroutput on
Sql>exec fnd_aolj_util.getclassversionfromdb(‘oracle.apps.inv.transaction.server.BaseTransaction‘);
>>> Class: oracle.apps.inv.transaction.server.BaseTransaction
$Header: BaseTransaction.java 115.235.115100.55 2008/12/19 14:09:15 rkatoori
ship $
PL/SQL procedure successfully completed.
>
/>
>>... Java Versions - Via Application:
1. Login to application.
2. Click on Diagnostics link on top right
of the page
3. Click on "Show Pool Monitor" in drop down
4. Click on
Sessions icon in the table.
5. Click on Versions link in the left of
page
6. In Class Name field:
7. Enter
path/filename
Examples:
oracle.apps.inv.transaction.server.BaseTransaction
oracle.apps.ego.extfwk.user.common.EgoExtFwkCache
8.
Press Go button and version displays
Report Versions
A report similar to forms can be found on the file system. However,
you first must determine the shortname of the report in question. You then look
in the specific product directory under reports. Since the report is a binary
file, you would use a strings command to convert the binary code into
characters, then grep for the version looking for $Header. For example,
find the Bill of Material Structure Report (BOMRBOMS.rdf) version with something
like:
$
strings -a $BOM_TOP/reports/US/BOMRBOMS.rdf |grep ‘$Header‘
$Header: BOMRBOMS.rdf 120.5.12000000.5 2008/01/30 22:16 pgandhik noship
PL/SQL Packages
A PL/SQL Package is most often a routine written in the database. The
Oracle Application delivers the source code as well as installing the package
into the database. It is often a good idea to check the version directly
in the database to be sure what version you are using. However, checking
the file system for the source code is often a good enough indicator of what is
installed since they are normally synchronized.
SQL> select text from dba_source
2 where
3 name = upper( ‘INV_TXN_MANAGER_GRP‘)
4 and line < 3;
TEXT
--------------------------------------------------------------------------------
PACKAGE INV_TXN_MANAGER_GRP AS
/* $Header: INVTXGGS.pls 120.4.12000000.1 2007/01/17 16:33:03 appldev ship $ */
PACKAGE BODY INV_TXN_MANAGER_GRP AS
/* $Header: INVTXGGB.pls 120.55.12000000.15 2007/10/25 11:02:58 ksaripal ship $
*/
You could also check the file system for the version. This is
less accurate as it might not be the version currently used in the database, but
generally it is close enough. Note that you do not need the ‘STRINGS‘ command
because the package details (.pls) is a string file already. Therefore, you can
directly open the file in an editor like vi to see the contents and the version.
Or you can "grep" the contents searching for the "$Header"
that usually accompanies the version number. To get the version from the
file system using "grep", you can do something
like:
grep ‘$Header‘ $INV_TOP/patch/115/sql/INVTXGGB.pls
/* $Header: INVTXGGB.pls 120.55.12000000.15 2007/10/25 11:02:58 ksaripal ship $ */
Definition Files
Definition files like .ldt, .xdf, .odf, etc. are similar to PL/SQL in
that they are already text files so you can directly open the file to see the
version or grep for the version. These files usually store information about
setup, object definitions, etc. They will be found on the file system and then
are loaded into the database will a specific command like adodfcmp that is used
for .odf files. (.odf loads tables and views, .ldt creates indexes, .xdf creates
objects like materialized views). Another interesting command in .odf
files is that you can compare the definition listed on the file system to that
in the database to confirm that they are the same. Here is an
example:
adodfcmp odffile=$ENG_TOP/patch/115/odf.engeeco.odf userid=eng/eng changedb=no priv_shema=system/manager mode=tables touser=apps/appsLanguages
If you are using multiple languages, remember that the objects are
often distributed in each language. Therefore, you should check the version of a
report, form, etc. in each language.
Patch Versions
... Patch Versions - Oracle Applications
It is sometimes useful to see if a particular patch has been applied.
To avoid any confusion, it is often more helpful to first look up the version
that the patch delivers and then see if you have that version or higher.
However, if you want to see if an Oracle Application patch is applied you can
check the patch table or if the bug is logged. Checking for the bug is generally
more consistent because you might not have installed the exact patch but
received the bug fix in a rollup patch or higher level fix. You could
check the bug table AD_BUGS with something like:
select bug_number, application_short_name "App", bug_status, success_flag, last_update_date
from ad_bugs
where bug_number =‘7425435‘;
Or the patch table with something like:
select substr(patch_name,1,12) patch_num
from ad_applied_patches
where patch_name like ‘7425435‘;
When a patch is applied, version information is also written for
each file. This is included in the AD_FILES and AD_FILE_VERSION tables.
Sometimes if a patch goes wrong, you apply a test patch, or you manually
install/load a file, the versions in the AD tables will be incorrect. However,
they still can be useful and the following is an example to query the latest
version of a java file (RevisedItemEOImpl.class) :
select b.FILE_VERSION_ID,b.FILE_ID,b.VERSION,b.CREATION_DATE
from AD_FILES a, AD_FILE_VERSIONS b
where a.file_id = b.file_id
and a.filename like ‘RevisedItemEOImpl.class‘;
FILE_VERSION_ID FILE_ID VERSION
--------------- ---------- -------
654136 401028 115.23
738571 401028 115.24
760052 401028 115.27
959429 401028 115.30
1018955 401028 115.32
1525148 401028 120.36
6 rows selected.
... Patch Versions - Server/Database
A server patch like a database patch is NOT stored in the same place.
For database patches, you would look in the ‘Inventory‘. For
example:
$ opatch lsinventory