關于在Oracle EBS環境下如何查找數據源的文章幾年前就已經開始整理，但是其中關于OAF方面的一直沒有整理，導致這份文檔一直殘缺不全，

有很多次同事都向我索要相關文檔都未能如愿以償，新的一屆培訓工作再次啟動，為了自己也能夠“一勞永逸”，將相關內容整理發出。

在Oracle E-Business Suite 環境下進行二次開發，要求技術顧問對EBS系統的結構和實現有一定的了解，同時熟悉系統的關鍵流程，進而掌握后臺的表結構設計，查找數據源需要達到的兩個目的是：

到對應的數據庫對象：視圖或表

找到界面中字段對應后臺的表列

本文先介紹如何查找Form界面對應的數據源，快速找出FOrm界面后臺對應的表/視圖以及對應的列，

Form本身特有的特點，致使查找Form界面所對應的后臺數據源變得相對簡單方便。

一、使用“查看—> 歷史記錄”功能

“歷史紀錄”可以找出數據塊對應的后臺數據庫對象，并不能找出字段所對應的數據庫列。

適用場合：適用于基于數據庫塊的數據源查找

前提：光標停留在需要查詢數據源的數據塊中，并按某個條件查詢出數據

步驟：

選擇菜單：Help –> Record History(幫助 –> 歷史紀錄)

查看彈出窗口中Table Name的值，這個值便是光標所在數據塊對應的后臺數據庫視圖或數據庫表

實例(查找用戶所對應的后臺數據庫對象)：

光標定位于User Name字段

執行查詢，查詢出SYSADMIN用戶信息

選擇菜單：Help –> Record History

彈出如下窗口,其中Table Name的值：FND_USER，既是后臺數據庫對象

限制：歷史紀錄”的方式只適用于基于數據庫塊的查詢；而對于非數據庫塊的后臺查詢沒有辦法使用，不能使用的地方會彈出如下的消息：

二、使用“查看 —> 診斷 –> 檢查”

通過檢查功能可以查找出字段對應后臺數據庫列信息，因此使用此方法的需要先找出對應的數據庫視圖或者表

步驟：

光標停留在Form界面中的一個字段

選擇菜單：Help —> Diagnostics –> Examine

在彈出的窗口中輸入數據庫用戶APPS的密碼，確定

彈出窗口中Field對應的值既是Form所對應的字段，一般情況下，此值既是數據列的列名

實例(查找出User Name字段所對應的后臺數據庫列)：

光標停留在User Name字段中

選擇菜單：HelpàDiagnosticsàExamine

彈出如下窗口，輸入數據庫用戶APPS的密碼，確定

彈出如下窗口，Filed的值：USER_NAME就是User Name字段所對應的后臺數據庫列，因此本字段為：fnd_user.user_name

注意事項：使用此方法來查找數據列時，我們得到的只是Form字段的名稱，很多使用Form字段的名稱和所對應的數據源列一致，但是在少數情況下，Form字段名稱和后臺數據庫列名存在差異，這個使用此方法就無法100%適用，而需要通過名稱等進一步推測確認。

三、使用”Last Query”功能

使用最后查詢可以找出在Form中最后執行查詢的SQL語句，從而得知對應的數據源以及相關數據庫列信息

適用場合：同時適用于基于數據庫塊和非數據庫塊的數據源查找

步驟：

在Form中進行數據查詢

光標停留在Form界面中的一個字段上

選擇菜單：Help –> Diagnostics –> Examine

在彈出的窗口中輸入數據庫用戶APPS的密碼，確定

彈出窗口中，選擇Block為：SYSTEM，Field為：LAST_QUERY

Value中的SQL語句既是Form中最后查詢的語句

實例(找出并發管理器對應的后臺數據源)：

進入并發管理器界面，并進行查詢(自動查詢)，使用“歷史紀錄”方法無法得到表

選擇菜單：Help –> Diagnostics –> Examine，在彈出的窗口中輸入APPS用戶密碼

彈出窗口中，選擇Block為：SYSTEM，Field為：LAST_QUERY

取得Value為：

SELECT ROWID,

row_id,

concurrent_queue_name,

user_concurrent_queue_name,

target_node,

max_processes,

application_id,

concurrent_queue_id,

control_code,

manager_type

FROM fnd_concurrent_queues_vl

WHERE enabled_flag = 'Y'

ORDER BY decode(application_id, 0, decode(concurrent_queue_id, 1, 1, 4, 2)),

sign(max_processes) DESC,

concurrent_queue_name,

application_id

這樣可以取得數據庫視圖：FND_CONCURRENT_QUEUES_VL

限制：由于Last Query中查詢到的SQL語句是Form中最后一次查詢的語句，因此如果需要查找像主從關系中主塊數據源就沒有辦法適用

四、使用SQL Trace功能

使用SQL Trace功能，可以知道在Form操作過程中，對數據庫系統進行了哪些查詢、DML和DDL操作，可以全面的查看與數據庫有關的操作和性能統計信息。

此方法是這些方法中功能最強大，同時也是最復雜的一個，而且它經常成為性能調試中的一個得力工具。

步驟：

啟動Trace模式

在Form中進行操作，并保證操作有查詢、插入、更新或刪除動作

關閉Trace模式

登陸數據庫服務器

使用Tkprof工具格式化Trace結果文件輸出

查看被格式化過的Trace文件

推測驗證數據源

實例(定義一個用戶時，找到后臺所進行的DML操作，進而找到后臺數據源)：

打開Form界面進入輸入狀態，還是以上面使用的User界面為例

選擇菜單：Help –> Diagnostics –> Trace –> (Regular Trace, Trace with Binds, Trace with Waits, Trace with Binds and Waits)

記下Trace文件路徑及名稱

在界面上操作，輸入信息，保存

選擇菜單：Help –> Diagnostics –> Trace –> No Trace，失效Trace功能

使用數據庫操作系統用戶Telnet到數據庫服務器，切換到$ORACLE_HOME/admin/_/udump(上面所顯示的路徑)

使用Tkprof命令格式化Trace輸出：tkprof demo_ora_21088_SYSADMIN.trc demo_ora_21088.out

五、查看Form源代碼

對于Form應用來說，如果上面的方法還不足以滿足需求的話，可能就需要采用最徹底的辦法了，直接查看Form的源代碼，我想這個方法是最能夠解決問題的方法了，但是由于需要查看源代碼，對于查看的人員就需要熟悉Form的開發，因此一般情況下不先推薦使用它，但是對于如果希望完全搞清楚Form應用后臺邏輯的情況下，也只能采用這種方式。

此方法在此就不做介紹了，此方法可以說只適合Form開發人員使用。

上面的方法是Oracle EBS二次開發中最常用最有效的方法，在Form相關的開發和應用中，掌握的以上的方法基本上能夠解決絕大多數的問題。

后續將放出Oracle EBS環境下查找數據源的OAF篇。