oracle存儲過程轉達夢8存儲過程時踩過的坑

達夢存儲過程的語法與oracle的高度類似，但有好多細節仍是有差別。我在此次項目遷移中踩過很多小坑，在這裏給你們分享一下。

說明一下，我用的版本是達夢8，遷移時碰到的問題有些我已經反饋給達夢的官方羣管理員，估計之後會有修復。

rpad問題

達夢的rpad函數，計算中文時永遠是認爲一箇中文字符中兩個字節，即便數據庫設置的字符集是utf8（目前就發現rpad/lpad函數有這個問題，其它字符串函數都能正確識別，當字符集是utf8時能識別出來一個字符中3個字節）

測試代碼：

select rpad('我是hch', 6), lengthb('我是hch') from dual -- 達夢輸出"我是hc 9"
union all
select rpad('我是hch', 5), length('我是hch') from dual -- 達夢輸出"我是h 5" 
union all
select rpad('我是hch', 3), length('我是hch') from dual; -- 達夢輸出"我 5"

這個問題達夢的工做人員說之後會修復，目前個人解決方法是本身寫一個rpad函數

function rpad_dm(string varchar2, padded_length number, pad_string varchar2 := ' ')
    return varchar2 IS
    v_len number := lengthb(string);
  BEGIN
  	    dbms_output.put_line('v_len - padded_length = ' );
  	if padded_length < v_len THEN
  		return substrb(string, 1, padded_length); --若是輸入長度小於原字符串長度，則調用substrb截斷
  	elsif padded_length = v_len THEN
  		return string; --若是長度相等直接返回原串便可
  	else
  		return string || rpad(' ', padded_length - v_len, pad_string); --若是長度大於原字符串，則在後面補空格
  	end if;
  END;

短路問題

通常編程語言都會提供短路功能，在計算與或邏輯時，若是前半段邏輯已經能肯定真假時，後半段邏輯不會執行。

plsql裏面也實現了短路功能，咱們通常會利用這個特性減小一些代碼，例如先判斷變量是否爲空，若是不爲空再使用變量作運算：

if (var is not null and va.exists('error') ) then dbms_output.put_line('yes'); fi;

但在達夢的存儲過程，短路卻沒有實現。上面的代碼無論var是否爲空，都會進行va.exists('error')這個邏輯。若是不幸var的變量是空的，就會致使運行異常。

測試代碼1：

dbms_output.enable;
declare
  v_flag boolean;
begin
  -- 請問這個存儲過程執行異常，報"非法的參數數據"  是否是達夢的bug oracle下是能夠正常運行的
  -- 仍是有什麼設置可讓存儲過程正常執行
  if  (to_number('1') != 1) and to_number('abc') = 1 then
    dbms_output.put_line('yes');
  end if;
  dbms_output.put_line('ok');
end;

測試代碼2：

dbms_output.enable;
declare
       TYPE TEST_RPT_LIST IS TABLE OF number INDEX BY PLS_INTEGER;
       o_demo_list TEST_RPT_LIST;
       i_report_id number := 17410491;
BEGIN
  -- 驗證達夢8 if短路
  select 1 BULK COLLECT INTO o_demo_list from dual;
  dbms_output.put_line('o_demo_list(1) = ' || o_demo_list(1));


  if o_demo_list(1) = 1 or o_demo_list(2) = 2 THEN -- or 短路沒問題
  	dbms_output.put_line('or yes'); -- or yes能正常輸出
  end if;

  if o_demo_list(1) != 1 and o_demo_list(2) = 2 THEN -- o_demo_list(1) != 1 不成立  爲何還要執行o_demo_list(2) = 2判斷
    dbms_output.put_line('and yes'); -- 這裏永遠不該該輸出
  end if;

  dbms_output.put_line('done'); -- 走不到done
EXCEPTION
  WHEN no_data_found THEN
     dbms_output.put_line('no_data_found tbl_demo_tab ' || 'ID ' || to_char(i_report_id));
  WHEN OTHERS THEN
    -- RAISE;
    dbms_output.put_line('err:' || sqlcode || sqlerrm);
END;

不僅是if有短路問題，decode，case when等相似的都會有短路問題。

"case 判斷 when 表達式1 else 表達式2 end" 在oracle是若是條件成立則執行條件1並返回其值，而在達夢是同時執行表達式1和表達式2，並根據判斷結果返回一個值。

解決方法是不要偷懶，不依賴短路實現，多寫幾個if判斷，或者把decode拆成多個if else語句。

深淺拷貝問題

oracle的table數組變量的賦值，默認是值複製（即深拷貝），而達夢默認是引用複製（即淺拷貝）。

也就是說在oracle使用 tmpArr := arr (tmpArr 和arr 都是數組)，而後對這個tmpArr操做，不會影響arr的值，而在達夢，修改tmpArr數組元素的內容就是在修改arr

測試代碼

FOR vv IN 1 .. 5 -- crontab 初始化賦值
        LOOP                
                CASE vv
                WHEN 1 THEN
                        v_obj.minutes := tmpArr;
                WHEN 2 THEN
                        v_obj.hours := tmpArr;
                WHEN 3 THEN
                        v_obj.days := tmpArr;
                WHEN 4 THEN
                        v_obj.months := tmpArr;
                WHEN 5 THEN
                        v_obj.weeks := tmpArr;
                END CASE;
        END LOOP;

在oracle對v_obj這樣賦值後，v_obj.minutes和v_obj.hours是兩個不一樣的變量，分別對兩個變量修改，相互之間不會出現干擾。而在達夢8，v_obj下面全部變量都指向同一個數組，對v_obj任意一個成員修改，都會同時影響其它成員的值。

解決方法是本身寫一個數組拷貝函數，例如這樣：

function copy1kList(v_input t_str_list) return t_str_list IS
    v_tmplist t_str_list;
    v_ind PLS_INTEGER;
  begin
    --TYPE t_str_list  IS TABLE OF VARCHAR2(1024) INDEX BY PLS_INTEGER;
  	if v_input.count > 0 then
  		/*
  		//在v_input裏面的元素不連續時，這樣會有bug
  		for vv in v_input.first .. v_input.last LOOP
  			v_tmplist(vv) := v_input(vv);
  		end loop;
  		*/
  		v_ind = v_input.first;
  		while v_ind is not null
  		loop
  			v_tmplist(v_ind) := v_input(v_ind);
  			v_ind = v_input.next(v_ind);
  		end loop;
  	end if;
  	return v_tmplist;
  end;

使用這個函數代替數組變量賦值就能維持代碼行爲與oracle一致。

今天暫時先分享這三個問題，後面有時間再整理其它坑。這些坑比較隱蔽，花了我很多時間調試才發現，我把它們總結出來，但願能對你有所幫助。