Oracle APEX开发实战：环境搭建、权限布局与EBS集成

简介：面向Oracle APEX初学者与具备一定Oracle基础的中级开发者，《Oracle APEX深入浅出》以单份doc技术文档形式，系统梳理从环境搭建到企业级应用开发的完整路径，重点解决APEX入门缺少体系、控件与报表使用不熟、页面美化和部署集成缺少参照等问题。压缩包内共1个doc文件，大小约8.11MB，内容按章节组织，涵盖APEX简介、账户与权限管理、开发概要、页面布局美化、常用控件、Report增删改、文件上传下载、CSS与JS应用、图表报表、插件使用、部署、调试技巧与API，以及APEX与EBS集成等模块。已有1593人学习，文档以开发指南形式串联知识点，便于读者按目录查阅环境配置、控件选型、报表设计、前后端脚本和集成调试思路，适合作为日常开发的手册与查漏补缺的参考。

1. APEX 到底解决什么问题：一个 PL/SQL 团队的非典型选择

接手一套跑在 Oracle EBS 旁边的内部系统，几十张表，需求方只提一条：浏览器里能查、能改、能导出。团队里全是写 PL/SQL 的老手，没人愿意为几个表单再上一套 Java 框架。Oracle APEX 就是在这种局面下被翻出来的——页面全部存在数据库里，渲染靠 PL/SQL 拼 HTML 往外吐，开发、部署、运行三件事都在浏览器里完成，客户端除了浏览器什么都不用装。这份 Oracle APEX 开发指南从卸载自带旧版、建表空间、配嵌入式网关讲起，一路覆盖账户体系、Grid Layout 页面布局、控件与 Dynamic Action、Tabular Form 多行增删改，最后落到 EBS 里挂 APEX 页面调用。适合手上有 Oracle 库、想把内部表单类应用快速搬到浏览器上的团队，也适合想搞清楚 APEX 到底能扛多大场面的人。

2. 环境搭建：从卸掉自带 3.0 到嵌入式网关跑通 4.2.5

这一章是整个资源里最经得起复现的部分，也是翻车最密集的部分。APEX 的安装不像装个中间件那样解压即用，它往数据库里塞了上千个 PL/SQL 对象和一个独立 schema，装错一次基本等于重来。下面按「先清场、再建库、后开口」的顺序走一遍，每一步都写清楚为什么。

2.1 为什么先卸载再安装：3.0 的残留会咬人

Oracle 11g 数据库自带 APEX 3.0，对应的 schema 是APEX_030200；要装的 4.2.5 对应APEX_040200。两套 schema 名字不同，看起来互不干扰，问题出在访问入口上：/apex/apex_admin这个 URL 最终走哪套包、登录校验调的是哪个版本的存储过程，取决于 EPG 配置里 DAD 指过去的位置和同义词解析顺序，而不是你以为的「新的覆盖旧的」。原文里那位作者改了三遍 ADMIN 密码、重启数据库都登不进去，根因就是老版本的校验逻辑还在生效。

动手前先确认库里到底躺着几套：

-- 以 SYSDBA 连接后执行，列出所有 APEX 相关 schema 及其状态 SELECT username, account_status, created FROM dba_users WHERE username LIKE 'APEX%' OR username IN ('ANONYMOUS', 'APEX_PUBLIC_USER') ORDER BY created;

这条查询的用处是把「隐形残留」变成「可见清单」。正常情况下 11g 新库只有APEX_030200、APEX_PUBLIC_USER、ANONYMOUS三个。如果看到多个APEX_0x0x00并存，就别急着装新版，先把老的清干净。account_status里如果是LOCKED，说明对应账户从没被解锁过，这在后面配网关时是要单独处理的，跟安装本身无关。

卸载脚本在旧版 APEX 的解压目录里，一般叫apxremov.sql。执行前把当前目录切到那份旧安装文件所在位置，用 SQL*Plus 以 SYSDBA 连库：

# 进到旧版 APEX 安装脚本目录，用 SYSDBA 执行卸载 cd $ORACLE_HOME/apex_old sqlplus / as sysdba

-- 卸载旧版本，脚本会依次删除 schema 和同义词 @apxremov.sql

逻辑说明：这个脚本做三件事——删掉APEX_030200schema 及其全部对象、清理指向它的公共同义词、移除 EPG 里已注册的 DAD。参数说明：无入参，但执行过程中会提示确认，交互式输入YES。跑完之后用 2.1 那条查询复核一遍，确认APEX_030200已经不在了再往下走。注意别在同一个 SQL*Plus 会话里连续执行卸载和安装，中间断开重连一次，避免会话里缓存的同义词解析结果干扰判断。

2.2 表空间、安装脚本与中文语言包

APEX 自己的对象和静态文件建议单独放一个表空间，别跟业务表挤在一起。100M 起步、自动扩展、封顶 1G，对内部系统够用很久：

-- 给 APEX 单独划一块地，路径按实际库的 db_create_file_dest 改 CREATE TABLESPACE APEX01 DATAFILE '/u01/app/oracle/oradata/<SID>/apex01.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 1000M;

参数说明：DATAFILE的路径别照抄，用SHOW PARAMETER db_create_file_dest看一眼实际存储位置再改；AUTOEXTEND ON NEXT 100M是每次扩 100M，不是一次扩到 1G，MAXSIZE才是上限。生产环境把这个上限调大一些，APEX 的元数据增长比想象中快，尤其是应用数量多、页面改动频繁的时候。

安装文件上传到$ORACLE_HOME下解压，然后执行安装脚本。这个脚本的参数顺序是固定的四个：APEX 对象表空间、APEX 静态文件表空间、临时表空间、图片虚拟路径。

# 解压到 ORACLE_HOME 下，避免后续权限和路径问题 cd $ORACLE_HOME unzip apex_4.2.5.zip -d apex cd apex sqlplus / as sysdba

-- 四个参数：对象表空间、文件表空间、临时表空间、图片虚拟目录 @apexins.sql APEX01 APEX01 TEMP /i/

逻辑说明：apexins.sql会先建 schema、再灌元数据表、最后把静态资源（CSS、JS、图片）写进数据库里的 XDB 仓库。第四个字面量/i/是虚拟路径，浏览器请求http://host:8888/i/...时由网关映射到库内的资源，不是磁盘目录。参数说明：如果库的临时表空间不叫TEMP，用SELECT property_value FROM database_properties WHERE property_name='DEFAULT_TEMP_TABLESPACE'查一下再替换；图片路径保持/i/不动，改了要同步改后面 EPG 配置里的映射。

装完顺手把中文语言包灌进去，不然开发者面对的是全英文界面，交付给业务方时也不好看：

# 语言包在解压目录的 builder/zh-cn 下，用 SYSDBA 执行 cd $ORACLE_HOME/apex/builder/zh-cn sqlplus / as sysdba

-- 把中文语言包注册进 APEX 元数据 @load_zh-cn.sql

逻辑说明：语言包不是界面翻译文件，而是一批写进 APEX 元数据表的种子数据，装完要在 ADMIN 的「管理服务 → 消息」里把默认语言切成中文才生效。参数说明：无。这一步失败通常是因为当前会话的 schema 不对，脚本要在APEX_040200上下文里跑，报错就检查ALTER SESSION SET CURRENT_SCHEMA是否指对了。

2.3 嵌入式 PL/SQL 网关：8888 端口怎么开出来

11g 自带的 EPG 是最省事的入口，不用单独装 Apache 或监听器。配置脚本需要传 APEX 解压目录作为参数，把静态文件路径和 DAD 一次注册进去：

-- 参数是 APEX 解压目录，脚本会配好 /i/ 和 /apex/ 的映射 @apex_epg_config.sql /u01/app/oracle/apex

然后开端口。这一步是关键，不开端口的话服务起得来但外部访问不到：

-- 设置 EPG 监听端口，改完必须 COMMIT 才生效 EXEC DBMS_XDB.SETHTTPPORT(8888); COMMIT; -- 验证端口当前值 SELECT DBMS_XDB.GETHTTPPORT FROM DUAL;

参数说明：8888 是原文用的端口，换成 8080、80 都行，但 80 需要额外权限，内部系统建议避开。COMMIT那句不能省，SETHTTPPORT是 DDL 语义的操作，不提交的话下一个会话看到的还是旧值——这个坑很多人踩过，改完不生效先怀疑没提交。

接下来处理两件账户的事。一是解锁匿名用户和公共用户，EPG 模式下未认证的请求走ANONYMOUS，认证流程走APEX_PUBLIC_USER，这两个锁着的话页面直接 404 或 401：

-- EPG 模式下这两个账户必须可用 ALTER USER APEX_PUBLIC_USER ACCOUNT UNLOCK; ALTER USER ANONYMOUS ACCOUNT UNLOCK;

二是给APEX_040200开放出网权限。APEX 里如果用到了 Web 服务、远程图片、邮件这类功能，需要在 11g 的 ACL 里显式授权，否则运行时报ORA-24247：

-- 给 APEX schema 建一条 ACL，允许其访问外部主机 BEGIN DBMS_NETWORK_ACL_ADMIN.CREATE_ACL( acl => 'apex_net.xml', description => 'APEX outbound network access', principal => 'APEX_040200', is_grant => TRUE, privilege => 'connect'); DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL( acl => 'apex_net.xml', host => '*'); COMMIT; END; /

参数说明：principal必须是 APEX 的 schema 名，写错成APEX_PUBLIC_USER不生效；host => '*'表示不限目标主机，内部环境可以接受，收紧的话换成具体域名或 IP 段。这段脚本在 12c 之后语法有变化，跨版本迁移时不能直接搬。

最后改 ADMIN 密码。4.x 有独立脚本，别用ALTER USER硬改，因为 APEX 的 ADMIN 密码在元数据里还有一份校验信息，两处不一致会导致登录失败：

-- 交互式修改 ADMIN 密码，要求大小写+数字+特殊字符 @apxchpwd.sql

全部走完，浏览器打开http://<host>:8888/apex/apex_admin，能看到登录框就说明网关这一层通了。如果页面上只出现静态文字没有样式，说明/i/的映射没配对，回头查apex_epg_config.sql的参数路径。

3. 账户、Workspace 与 Application：三级权限怎么落到人头上

APEX 的权限模型跟一般 Web 框架不一样，它不是「用户 → 角色 → 权限」那套，而是嵌套了四层：数据库 schema 在最底下，上面盖 Workspace，再上面是 Application，最上面才是用户。搞不清这四层的对应关系，后面配认证时全是玄学。

3.1 Workspace 与 Schema：一个工作空间就是一个工程

Workspace 是 APEX 里的隔离单位，一个 Workspace 绑定一个数据库 schema。同一个 schema 可以被多个 Workspace 绑，但一般不这么干，因为建 Application 时用的连接就是 Workspace 绑定的那个 schema，权限边界完全由它决定。

原文的做法是把 Workspace 直接绑到 EBS 的APPSschema 上，理由是后续要跟 EBS 集成，省掉跨 schema 授权的麻烦。这个选择在开发环境能省事，生产环境要掂量：APEX 里写的每一条 SQL 都以APPS身份执行，等于把 EBS 的全部权限敞开了，页面里一个疏忽的DELETE就是事故。我一般的做法是开发期绑APPS图快，上线前单独建一个受限 schema，只授必要的对象权限和 synonym，代价是要补一批同义词，但换来的隔离值这个钱。

建完 Workspace 后想确认绑定关系，可以查元数据视图：

-- 以 APEX_040200 身份查，列出所有工作空间及其对应 schema SELECT workspace, workspace_display_name, apex_users FROM apex_workspaces ORDER BY workspace;

参数说明：apex_users是这个工作空间下的账户数，装上没多久就几十个的话，说明默认账户没清理干净，后面配权限时容易搞混谁是谁。视图名在 4.x 和 5.x 之间有变化，跨版本查的时候先DESC一下确认。

3.2 ADMIN、Workspace 管理员、开发者、终端用户四级

这四级的职责边界很清晰，混用的后果是权限泄漏或者开发效率低。

原文的操作路径是：先用 ADMIN 登进去建一个 Workspace（比如叫ws_demo，schema 选业务 schema），建的同时会要求指定这个 Workspace 的管理员；然后以这个管理员登录，在「管理用户」里加两类人——Developer 和 End User。这一步很多人图省事，把开发者直接加成 Workspace 管理员，结果是任何人都能改认证方案、能导出整个应用，出事之后查不到是谁动的。

判断某个账号在哪一层，用这条 SQL：

-- 查某个工作空间下的账户清单和角色 SELECT apex_user, user_name, is_admin, is_application_user, account_locked FROM apex_workspace_apex_users WHERE workspace = 'WS_DEMO';

is_admin为Y是 Workspace 管理员，is_application_user为Y是终端用户，两个都为Y说明既是管理员又能登录应用——这种账号应该尽量少，只留项目负责人一个。account_locked是独立开关，跟数据库账户的锁定不是一回事，APEX 里连续登录失败锁定的是这个字段。参数说明：workspace要大写，小写查不出来。

3.3 Application 的登录认证与 Page 0 全局页

建 Application 时会让选认证方案，4.x 自带七种，常用的就两种。Application Express Accounts走 APEX 自己维护的账户表，适合纯内部、不跟外部系统打通的应用；HTTP Header Variable依赖前置网关传头，适合已经有一套统一认证、需要免登的场景。选错了后期可以改，在「共享组件 → 认证」里换，但换完要把所有页面的授权方案跟着调，不然会出现「认证过了但页面进不去」的哑巴亏。

Page 0 是这个 Application 的全局页，不放任何可见组件，专门用来挂全局项（Global Page Items）和应用级计算。它不是必须的，但只要你的应用里出现了「每个页面都要用到的常量或当前登录人信息」，就该建。

常见的做法是在 Page 0 上建几个隐藏项，用 PL/SQL 计算出来：

-- Page 0 的计算项，类型选 PL/SQL Function Body DECLARE l_count NUMBER; BEGIN -- 取当前登录人在业务表里的岗位信息 SELECT COUNT(*) INTO l_count FROM t_user WHERE login_name = :APP_USER; IF l_count = 0 THEN RETURN 'GUEST'; END IF; RETURN 'STAFF'; END;

逻辑说明：结果赋给G_ROLE这样的应用级项，任意页面用:G_ROLE就能取到。参数说明：APP_USER是 APEX 内置的会话变量，存当前登录名，不要自己再定义一个同名项。计算点的执行时机选「After Header」比较稳，选「Before Header」的话有些认证信息还没初始化完，取到空值。这段逻辑有个隐患——每渲染一页都查一次库，页面多、并发高的时候是笔开销，能缓存就缓存到应用项里，或者在登录后事件里算一次。

4. 布局、控件与 Tabular Form：把增删改从跳页改成不跳页

APEX 4.1 之前，区域列的宽度和位置是全局的，改一个区域会影响整页；4.2 之后引入了 Grid Layout，每个子区域都能单独配。理解这套配置的前提是知道它最终翻译成什么 HTML——不然你永远在「配了没效果」和「效果跟想的不一样」之间打转。

4.1 Grid Layout 的三个开关对应 TABLE/TR/TD

APEX 的主题页面结构本质上是DIV + TABLE混排，Body 区域渲染成<TABLE>，Position 区域渲染成<DIV>。Grid Layout 面板上那三个开关，一一对应 HTML 表格的层级：

原文那个搜索区的例子配出来是这样：

新手最容易犯的错是把三个开关当成独立的样式属性，实际上它们有依赖关系：Start New Grid为No的前提是前面已经有一张表，Column的值不能超过这张表已定义的列数。判断一个区域的配置对不对，最直接的办法是打开页面按 F12 看渲染出来的 DOM，对照表格结构一眼就能看出哪一层不对。

4.2 控件属性、校验与 Dynamic Action 的执行顺序

控件本身的属性面板不算复杂，真正需要记的是几个条件类属性：Value Required、Condition Type、Read Only Condition Type、Default value、Format Mask。前三个是「什么情况下必填/显示/只读」，配的是 PL/SQL 表达式或 SQL 查询，不是布尔常量——想写死TRUE也能写，但那就失去了条件化的意义。

校验（Validation）和动态动作（Dynamic Action）是两套机制，执行时机完全不同。校验在服务端、提交时跑；Dynamic Action 在浏览器端、事件触发时跑。混用会出问题，比如指望 Dynamic Action 拦住非法数据提交——拦不住，用户禁用 JS 就绕过去了。

原文的例子是这样：点SEARCH2_BTN时校验P1_X_TEXT是否为空，但前提是t_user表里存在user_id='123'的记录。校验类型选Function Returning Boolean，条件类型选EXISTS (SQL query returns at least one row)：

-- 校验表达式：返回布尔，true 表示通过 BEGIN IF :P1_X_TEXT IS NOT NULL THEN RETURN TRUE; END IF; RETURN FALSE; END;

配套的条件 SQL：

-- 条件表达式，返回至少一行才执行上面的校验 SELECT 1 FROM t_user WHERE user_id = '123';

逻辑说明：条件 SQL 返回零行时，整个校验被跳过，用户点按钮什么都不会发生——这是「条件不满足就静默通过」的设计，不是 bug。参数说明：:P1_X_TEXT是页面项，冒号在 PL/SQL 里不能省；RETURN FALSE触发的错误信息在Error message里配，显示位置建议选「Inline with Field」，比弹窗体验好。

Dynamic Action 这边，原文配了两个：一个是P2_X_TEXT值改变时，根据是否为空显示/隐藏new search2区域；另一个是页面加载时把当前日期塞进日期选择器。

-- Set Value 动作的 SQL，给日期控件赋初始值 SELECT SYSDATE FROM DUAL;

逻辑说明：第一个 DA 的事件选Change、选择类型选Item(s)、项选P2_X_TEXT、条件选is not null，True Action 是 Hide Region，False Action 是 Show Region。第二个 DA 的事件选Page Load、条件选No Condition，True Action 选Set Value，类型选SQL Statement，受影响元素选日期控件。参数说明：Change事件不是每次按键都触发，是失焦后值确实变了才触发；要实时响应得用Key Release事件，但那样请求会很密集，表单类应用别这么干。

4.3 Tabular Form：基于视图的多行增删改与 Process

普通 Report 改一条记录要跳一个新页面，体验差、页面数还爆炸。Tabular Form 允许在一个表格里直接改多行、勾选删除、批量提交，代价是它比想象中难伺候。

原文的开发方式是基于视图建 Tabular Form，这跟 EBS Form 基于视图开发的思路一脉相承。建表和数据先准备好：

-- 班级表和用户表，用户表里带 class_id 外键 CREATE TABLE t_class ( class_id NUMBER, class_name VARCHAR2(50) ); CREATE TABLE t_user ( user_id VARCHAR2(50), resp_id VARCHAR2(50), resp_appl_id VARCHAR2(50), login_name VARCHAR2(50), class_id NUMBER ); -- 供 Tabular Form 使用的视图 CREATE OR REPLACE VIEW v_user_class AS SELECT u.user_id, u.resp_id, u.resp_appl_id, u.login_name, c.class_name FROM t_user u, t_class c WHERE c.class_id = u.class_id;

这里有个必须提前说清楚的点：这条视图带 JOIN，在 APEX 里默认是不可更新的。建 Tabular Form 时它会让你指定主键，user_id可以当主键用，但class_name这一列的写回需要额外处理——APEX 不会自动帮你反解到t_class表。原文的做法是绕开自动行处理，自己写 Process 全接管。

-- 提交按钮上的 Process，类型选 PL/SQL Anonymous Block DECLARE l_class_id NUMBER; BEGIN -- 遍历 Tabular Form 提交上来的行数组，G_F01 是勾选框 FOR i IN 1 .. NVL(APEX_APPLICATION.G_F01.COUNT, 0) LOOP IF APEX_APPLICATION.G_F01(i) = '1' THEN BEGIN -- 按班级名反查 class_id，查不到就报错 SELECT class_id INTO l_class_id FROM t_class WHERE class_name = APEX_APPLICATION.G_F03(i); EXCEPTION WHEN NO_DATA_FOUND THEN RAISE_APPLICATION_ERROR( -20001, '班级不存在：' || APEX_APPLICATION.G_F03(i)); END; -- 同步更新 login_name 和 class_id UPDATE t_user SET login_name = APEX_APPLICATION.G_F02(i), class_id = l_class_id WHERE user_id = APEX_APPLICATION.G_F04(i); END IF; END LOOP; END;

逻辑说明：G_F01到G_F04是 Tabular Form 按列顺序分配的数组，具体编号取决于你建 Tabular Form 时勾选了哪些列、顺序如何，建完要到页面的「Tabular Form Attributes」里逐个核对，写错一位就是改错字段。参数说明：NVL(..., 0)不能省，一行都没勾选时COUNT为NULL，FOR循环会直接抛异常；RAISE_APPLICATION_ERROR的错误码必须在-20000到-20999之间，超出范围页面捕获不到。

还有一个执行顺序的坑：Tabular Form 自带「自动行处理」（Automated Row Processing），如果你同时用了自动处理和自己写的 Process，两者谁先跑取决于 Process 在页面上的排列顺序。想让自己的逻辑在自动处理之前跑（比如先校验再落库），就把它拖到自动处理上面；顺序反了，自动处理已经把脏数据写进去了，你再校验也没意义。

5. 避坑与排查：安装、登录、布局、流程的五条记录

下面这几条都是实际装、实际配的时候撞出来的，每条按「现象 → 原因 → 解决」写。装在测试库上试错成本低，生产库上撞一次够记很久。

5.1 装完登录不上，ADMIN 密码改三遍都没用

现象：/apex/apex_admin页面能打开，输入 ADMIN 和新密码，转一圈回到登录页，没有任何错误提示。改密码、重启库、重装网关，全部无效。

原因：库里还残留着旧版本 APEX 的用户记录，登录校验走的是老 schema 下的过程。密码本身没问题，是校验入口指错了地方。原文作者最后用一条 SQL 查出来旧用户还在，drop 掉之后才通。

解决：装新版之前先按 2.1 那条查询确认APEX_0x0x00只剩一套。已经装完才发现的话，把残留 schema 连同其同义词一起清掉，再重新跑一遍apxchpwd.sql。清之前先导出dba_users和dba_objects里相关记录留档，别直接DROP USER ... CASCADE了事。

5.2 顺手 drop 掉 APEX_040200，只能重装

现象：清理残留用户时手滑，把新装的APEX_040200也 drop 了，或者 drop 完之后发现页面全部 500。

原因：这个 schema 不是普通用户，它装着 APEX 引擎的全部包和元数据，drop 掉等于把引擎拆了。APEX 没有「修复安装」这种选项。

解决：重新跑apexins.sql。重装前先把 EPG 里的 DAD 和/i/映射清掉，否则新装的会跟残留配置打架。这个坑的教训很直接——清理账户的脚本一定要先SELECT再DROP，把用户名写死在脚本里，别用LIKE 'APEX%'这种模糊匹配去批量删。

5.3 Grid Layout 的 Column 设了没反应

现象：子区域的Column改成 3，保存后刷新页面，位置一点没变，还是挤在第二列。

原因：Start New Grid为Yes的区域会新起一张表，新表的列数由第一个区域的Column值决定；后面的区域如果Column值超了这张表的总列数，会被浏览器忽略或者挤到下一行。另一种情况是父区域的Start New Row设成了No，子区域的列配置根本没机会生效。

解决：从最外层区域开始，逐层核对三个开关的依赖关系，别跳着改。改完按 F12 看 DOM，确认<table>的层数和<td>的个数跟预期一致。层级超过三层的话，建议先在纸上画一遍表格结构再配，比在界面上试错快得多。

5.4 Dynamic Action 选了 Change 但不触发

现象：文本框输入内容后，绑定的 Hide Region 动作没反应，手动刷新页面才看到效果。

原因：Change事件的触发条件是「值改变且失焦」，用鼠标点进别的输入框才算失焦；用 Tab 键切换也算，但如果是在文本框里按回车提交，事件顺序会变成先提交再触发，看起来就像没生效。另一个常见原因是 DA 的选择类型选了Item(s)，但项名写成了P2_X_TEXT带上了页面前缀，实际应该只写项名或者反过来，取决于当前页面。

解决：先在浏览器控制台确认事件到底有没有触发（APEX 的调试模式下 DA 会打日志），再确认When条件里的项名跟页面项完全一致。临时把条件改成No Condition验证动作本身能不能跑，能跑就是条件问题，不能跑就是绑定问题。生产环境记得把调试关掉，调试模式下每次请求都写日志，量大了会拖慢响应。

5.5 Tabular Form 的 Process 跑完数据没变

现象：点提交按钮，页面提示成功，数据库里一条都没更新。

原因：三种可能。一是G_F01这种数组编号跟实际列顺序对不上，IF判断永远为假；二是 Process 的执行时机配成了「Before Header」之类的前置点，那时行数组还没填充；三是视图带 JOIN 且没配主键保留，APEX 在提交前就把整行数据丢了。

解决：先在 Process 第一行加APEX_DEBUG.MESSAGE('COUNT=' || APEX_APPLICATION.G_F01.COUNT)，用调试模式看数组长度是不是零。是零就查执行时机和 Tabular Form 的主键配置；不是零就逐个打印G_F0x的值，对照页面上的实际输入。视图带 JOIN 的场景，老老实实关掉自动行处理，全部用自己的 Process 接管，别指望它自动反解。

6. 部署与验证：把应用从开发环境搬到验证环境的一套清单

APEX 的部署比想象中轻——应用本身就是一个导出文件，导入即用，没有编译打包那一步。但轻不代表没坑，导出的粒度选错、依赖对象没同步、认证方案跟着环境变了，这几种情况在验证环境里都会变成「本地好好的，一上去就报错」。

导出的粒度在 App Builder 里选，三个选项的区别值得记一下：导出整个应用（含所有页面、共享组件、授权方案）、只导页面、导应用但不含数据。跨环境迁移一般选第一个，导出的.sql文件里会带上应用 ID，导入到目标环境时如果 ID 冲突，APEX 会问你是覆盖还是新建，选新建会重新分配 ID，但页面里所有硬编码的应用 ID（比如f?p=100:1这种 URL）都会失效。

所以导入前先做一件事：把应用里所有硬编码的页面链接换成APEX_PAGE.GET_URL或f?p=&APP_ID.:1，用绑定变量代替写死的数字。这一步在开发期做最省事，事后补改要翻遍每个页面。

验证清单按顺序走，别跳：

跟 EBS 集成的那一步，原文放在最后讲，因为它是锦上添花而不是必需。做法是在 EBS 里注册一个 Function，类型选JSP或者HTML，把 APEX 页面的 URL 填进去，用户从 EBS 菜单点进去就是 APEX 页面；也可以在 Form 的按钮里直接调：

-- EBS Form 里打开 APEX 页面，URL 里带上业务参数 FND_UTILITIES.OPEN_URL( 'http://<apex-host>:8888/apex/f?p=100:1:' || :PARAMETER.SESSION_ID || '::NO::P1_USER_ID:' || :USER_ID);

参数说明：p=100:1里的 100 是应用 ID、1 是页面 ID，换应用就得改；SESSION_ID拼进去是为了让 APEX 复用 EBS 的会话上下文，不拼也能用，但用户每次点进去都要重新登录。这段代码在 11i 和 R12 上都能跑，但 URL 长度有限制，参数多的话建议只传关键 ID，其余在 APEX 端查。

这套东西我从装第一遍到现在，每次上新环境都要按第 5 章那几条重新核一遍，尤其是「卸旧版」和「drop 账户」这两步，宁可多花十分钟SELECT确认，也不愿意再体验一次重装。希望帮到你。

本文还有配套的精品资源，点击获取