實在對象如表格、Sequence、索引等建在本應用對應的用戶表空間中，其他對象如視圖、別名創建在Apps下，常見錯誤是新手把表建在APPS下，以后又來建別名，這個時候刪除別名時會報對象不存在，而建別名的時候又報對象已存在。 假如把腳本保存在文件里面，注重一個塊比如一個創建視圖的語句不要有空行，否則會出現如下情況：把語句拷貝到SQL Window能正常運行，用@執行文件卻報錯。 假如要執行execute_query，注重要go_block到適當的Block，但是go_block是個受限過程，并不一定都能成功 Master-detail關系： block both are database blockeach block has one item based on database displayed在PL/SQL Develop中沒有環境變量，所以假如要查詢多組織的View，需要先執行設置環境變量函數: BEGINfnd_client_info.set_org_context('83');END;GLOBAL變量對于所有form有效（可能是同一個應用，這個尚未驗證），而不僅僅是你所開發的form變量比如Global和Parameter的初始化應該在pre-form里面，在when-new-form-instance里面初始化不行，因為when-new-form-instance是在進入第一個導航塊的第一個item之后才促發的沒有屬性指名Block的記錄數，不過可以通過GET_BLOCK_PROPERTY(QUERY_HITS) 取得查詢到的記錄數hide_view并沒有真正hide一個畫布，只是放到最下層，所以假如上層的畫布沒有完全覆蓋下層畫布，下層的畫布很可能用戶還看得到；show_view則是把畫布放在最上層。 lov驗證的時候是驗證第一個可見的列，并且會把其他的返回值返回給各個Item，而不是僅僅驗證而已lov的查詢一般是針對第一列，但是假如我們把%放在最前面，則可以查詢所有列。 用Execute_query執行查詢的時候，會把Copy Value From Item里面的那個Item的值自動作為查詢條件。當創建記錄的時候也會直接用該值初始化，而且不改變記錄的狀態。在更新記錄的時候不知道會不會Copy過來尚未驗證。Get_Item_property的時候用ENFORCE_KEY屬性，但不能Set。該屬性在Master-detail設置的時候自動創建，刪除的時候自動刪除。假如不希望Copy Value From Item影響查詢結果，可以在Pre-Query里面把Item的值設為null。 app_query.reset('block_name');假如第一次調用，會把當前的DEFAULT_WHERE，然后什么都不做，以后再來調用的時候則會把第一次設置的DEFAULT_WHERE用set_block_property('SAA_HEADERS',DEFAULT_WHERE,...)設置回來，具體請參考app_core庫。 When-create-record的時候給Item賦值不改變記錄狀態。Sequence，假如我們在Item的Initial Value里面賦值，那么假如用戶Focus To新記錄，又回到老記錄，如此反復，Sequence會不斷變大的。 SQL Order BY的時候null值排在最后，這個一般不符合實際要求，可以這樣解決ORDER BY nvl(Geography_Code,chr(0))解決。 Trigger順序1： pre-commit塊1的pre-insert,on-insert,post-insert塊2的pre-insert,on-insert,post-insert...post-forms-commitTrigger順序2： when-list-changed在前，Validation item在后，因為Validation item是在要離開這個item的時候才促發的。 Trigger順序3： pre-form/when-create-record/pre-block/when-new-forms-instance/when-validate-record/on-insert/post-forms當定位到主塊的一個記錄，會促發子塊的when-clear-record事件和when-create-record事件，問題是假如主塊的是新記錄（未保存），在子塊的when-create-record里面取主塊的任何東西，居然是主塊的上一次獲得焦點的記錄的東西；連用取塊的當前記錄也是上一次獲得焦點的記錄。 Trigger順序4： post-changed在when-validate-item之前。所有的when-validate事件是當forms自己驗證通過之后才促發的。 禁用Clear功能可以通過在Form的key-clrblk里面調用app_exception.disabled，其實只是用Bell覆蓋默認的執行。 直接放在TAB Page上的Item，和放在堆疊畫布上的Item在設計時是無法“所見即所得”，所以建議把所有的Item根據需要放在不同的堆疊畫布上再堆到TAB Page上偽列Rownum在排序之前就已經決定，假如想得到排序后的Rownum，應當在嵌套一個Select語句；另外Where語句中的rownum只能用<或者<=，不能有>或者>=。 在SQL中用Over的時候，假如整個語句沒有Order by語句，最后的結果還是會排序的，規則是先按Over里面的Partition排序，在按Over里面的Order by排序。原因可能和分析函數的處理順序有關（8ifunctions.pdf有具體介紹）：先查詢到數據（Join/Where/Group By/Having），再運算分析函數（先分區，然后排序，再算Slide Windows，最后計算），最后是Order By。另外，一個疑問：我測試到的一個結果Group By似乎無法影響Partition，可是按照8ifunctions.pdf的說法，應該先執行Group By的，是不是因為Group By只是在第一階段的處理時作用在集合函數上，之后進入第二階段的處理就沒用了。 同事在裝8i的時候，連安裝界面都沒出來，而我機器可以裝，后來才知道原來他的機器是P4，無法正常安裝。 實際執行的Where條件，是我們設置DEFAULT_WHERE，再加上通過賦過值的Item。 注重：APP_FIND.query_range已經重載過，我們調用的時候可以不區分query_number_range或者query_date_range；觀察其代碼，發現也是通過給Item賦值來影響查詢的，只不過是賦值的時候，可能是加上 # between，# >=或# <=；這樣導致的一個結果是：Date類型的Item長度默認是11，被query_range這樣一搞，長度根本不夠，于是就導致諸如where REQUEST_DATE >= to_dat的錯誤，所以記得把字段長度加長，比如1000；總的來說，碰到From to的要小心長度。 當修改子類的時候，會自動更改很多屬性，非凡是Required，一定要注重。 當對塊進行刷新時，會修改很多Item的屬性，別以為你設置過了，Oracle就會記住。我碰到的情況是Insert Allowed等被自動改掉了！即使我的子類設置為Text_Item_Display_Only。 兩個變量，假如都為Null，判定還是不相等，所以必須用 a1 is null and a2 is null。所以在On-lock里面的if條件，我們可以把所以不可以為空的字段都寫成答應為空的形式。 一般來說，系統變量是很好用的。然而有時候并非如此，比如Current_Record，get_block_property('blockname',Current_Record)的結果并非總是一樣的，后者更加保險！非凡是剛打開Form的時候，在WHEN-NEW-RECORD-INSTANCE里面，前者是0，后者是1。 ''''表示一個單引號，''''''表示兩個單引號。應該是這樣理解，一個單引號表示轉義字符，首尾兩個單引號里面的內容表示字符串。 重啟Application： cd $APPLCSFcd scriptscd PROD./adstpall.sh apps/apps./adstrtal.sh apps/appsTrigger順序5： post-query，只有在界面可見的記錄才會促發，記錄從不可見變為可見時促發，促發過的記錄不再促發； 保存的時候會引發Post Item/Record/Block事件，因為要Navigate到Form。 數據庫org_id初始值to_number(decode(substrb(userenv('CLIENT_INFO'),1,1),' ',null,substrb(userenv('CLIENT_INFO'),1,10)))。 給非數據庫Item賦值；new記錄會變成insert（所以就不能按F11了）；query/changed記錄不變；new塊會變成query；query/changed塊不變。 對On-lock的理解，由于先入為主的緣故，開始一直很苦惱，為什么If里面只用了一個Return，Form怎么知道要鎖否？后來才知道On類型的數據庫觸發器是替換型的，On-lock也不例外，所以只要On-lock不Raise什么東西出來，Form就認為是鎖成功了，至于實際的鎖，我們有Select……For Update來完成，至于If判定只是進行更加嚴格的判定。 對Find的理解，開始也很納悶，為什么在Pre-query里面直接給Item賦值就可，不用自己拼語句，現在也逐漸發現里面大有文章。回想F11，這個時候的block其實是處于Enter-query狀態，輸入的東西Form會自動拼成Where語句（當然還要加上原來的default where，假如有Copy from item，也要加上），對于每個Item上輸入的值，一般是用 = ，假如有，就解析為like，假如有#，則把后邊的表達式（比如between，甚至是子查詢）直接作為條件；而當form內部執行堆棧Navigate到Pre-query時，block也是處于Enter-query狀態，道理和F11一樣，我們只管按業務查詢要求對Item賦值，剩下的就交給Form去處理了；需要注重的是當處于enter-query狀態的block，是使用query length屬性來限制輸入的數據長度，而不是通常的maximum lengh，只不過query length默認是0，即等于maximum lengh，所以會出現當用app_find.query_range時長度不夠的情況。