如何将给定Pro*C查询代码转换为PL/SQL存储过程

核心等价逻辑锚点 #

转换全程要对齐原Pro*C函数的所有业务分支，不能丢原有逻辑：

• 完整迁移代码里的K3变更注释，保留变更溯源链路
• 保持TAB1表按CARD_CUST_NO匹配的存在性判断规则完全一致
• 复刻原Pro*C的SQL错误捕获分支逻辑
• 保持查询结果标记的赋值规则不变，和原函数对调用方的返回含义完全对齐

逐模块转换对应关系 #

• K3变更注释迁移：把原Pro*C代码中所有带K3变更前缀的注释，原样挪到PL/SQL存储过程的对应逻辑段，带变更单编号的注释统一放在存储过程头部的注释块，不要随意修改注释内容，避免丢失审计追溯信息
• ProC预编译SQL转写：原ProC中用占位变量:card_cust_no做绑定的预编译查询，直接替换为PL/SQL的静态SQL，入参直接作为存储过程的IN变量绑定，不需要额外做动态SQL拼接。存在性判断用EXISTS实现，和原Pro*C中带ROWNUM=1截断的查询逻辑完全等价，避免无意义的全量数据提取
• SQL错误捕获逻辑迁移：原Pro*C中通过SQLCA结构检测的NO_DATA_FOUND、执行报错分支，直接对应PL/SQL内置的EXCEPTION异常块：
  • 触发NO_DATA_FOUND时，按原逻辑给存在性标记赋值为不存在的对应取值
  • 触发其他异常时，通过SQLCODE、SQLERRM获取错误码和错误信息，和原Pro*C的错误捕获行为对齐，可按需替换为原逻辑里的错误日志落库操作
• 存在性标记赋值：原Pro*C中查到匹配记录就给标记变量赋“存在”值、查不到赋“不存在”值的逻辑，直接在PL/SQL查询结果赋值阶段完成，保持初始值和原代码一致，避免调用方取值异常

可直接参考的实现模板 #

CREATE OR REPLACE PROCEDURE select_wk910_exist(
    pi_card_cust_no   IN  VARCHAR2, -- 对应原Pro*C的CARD_CUST_NO绑定输入变量
    po_exist_flag     OUT VARCHAR2,-- 对应原逻辑的存在性结果标记
    po_err_code       OUT NUMBER,   -- 对应原Pro*C捕获的SQL错误码
    po_err_msg        OUT VARCHAR2  -- 对应原Pro*C捕获的错误详情
)
IS
  -- 此处原样迁移所有K3变更注释，保留溯源信息，例：K3变更-20240312 适配卡号19位长度的校验规则
  v_check_flag VARCHAR2(1);
BEGIN
  -- 初始化变量，和原Pro*C的初始赋值逻辑完全对齐
  po_exist_flag := 'N';
  po_err_code := 0;
  po_err_msg := '';

  -- 等价实现原Pro*C的存在性查询
  SELECT CASE 
    WHEN EXISTS (
      SELECT 1 
      FROM TAB1 
      WHERE CARD_CUST_NO = pi_card_cust_no
      -- 原样迁移原Pro*C中其他的过滤条件，保持查询规则完全一致
    ) THEN 'Y' ELSE 'N' END
  INTO po_exist_flag
  FROM DUAL;

EXCEPTION
  -- 复刻原Pro*C的错误捕获分支
  WHEN NO_DATA_FOUND THEN
    po_exist_flag := 'N';
    po_err_code := 100;
    po_err_msg := 'TAB1表未匹配到对应CARD_CUST_NO的记录';
  WHEN OTHERS THEN
    po_err_code := SQLCODE;
    po_err_msg := SUBSTR(SQLERRM, 1, 200);
    -- 按需替换为原Pro*C中对应的错误日志输出/落库逻辑
END;
/

转换注意事项 #

• 原Pro*C里的客户端游标释放、预编译指令等数据库端无关的逻辑，不需要迁移到PL/SQL中，这类资源由数据库内核自动管理
• 原Pro*C中如果是用FETCH循环判断是否有记录的实现，换成EXISTS判断和原逻辑完全等价，效率更高，也不会出现游标资源泄漏问题
• 存储过程的入参、出参的类型长度要和原Pro*C中绑定变量的长度完全匹配，避免出现截断导致的判断误差

内容的提问来源于stack exchange，提问作者Megala