一般的に、Direct Open SQL 書き込み操作 (Insert/Update/Modify/Delete) は好ましくない方法ですので避けてください。これは、システムの完全性と安全性を台無しにするので使用すべきではありません。



Direct Open SQL 書き込み操作は、エラーを発生し易いので、システムが予期しない動作をする可能性があります。SAP で注意すべき問題は以下のとおりです。

- 複数のデータベース LUW にまたがる可能性がある SAP LUW (論理作業単位) 内でのデータの整合性を確保するために、「バンドルの更新」テクニックの使用をお勧めします。バンドルを更新せずにテーブル エントリを変更すると、SAP トランザクションが一貫性のないままになる可能性があります。

- Direct Open SQL 書き込み操作では、データベース レベルのロックのみを設定し、SAP アプリケーションのロックをバイパスします。これによって、デッドロックが発生し、データが破損する可能性があります。

- Direct Open SQL 書き込み操作では、アプリケーション プログラム内での SAP 認証チェックをバイパスします。

- テーブル エントリの書き込み、チェックの編集、監査トレールに標準のメカニズムが使用される場合、その後の更新 (たとえば、ドキュメントの変更など) のすべてが正しく実行されます。これは、Direct Open SQL 書き込み操作が使用される場合には該当しません。

実行者権限または AUTHID CURRENT_USER パッケージでは、現在のユーザースキーマに対して識別子が最初に解決されます。その結果、識別子がどのスキーマに属しているのかをコードの定義が明示していない場合、予期せぬ動作が引き起こされる可能性があります。

例: 次のコードは権限テーブルでユーザーを検索して、ユーザーがアクションを実行する権限を持っているかどうかを確認します。大半のユーザーは SYS.PERMISSIONS に対してのみ読み取りアクセスが許可されるようになり、定義済みの権限を変更できません。

CREATE or REPLACE FUNCTION check_permissions(
  p_name IN VARCHAR2, p_action IN VARCHAR2)
  RETURN BOOLEAN
  AUTHID CURRENT_USER
IS
  r_count NUMBER;
  perm BOOLEAN := FALSE;
BEGIN
  SELECT count(*) INTO r_count FROM PERMISSIONS
    WHERE name = p_name AND action = p_action;
  IF r_count > 0 THEN
    perm := TRUE;
  END IF;
  RETURN perm;
END check_permissions

check_permissions 関数をコールするユーザーがスキーマで PERMISSIONS テーブルを定義する場合、データベースが識別子を解決して、ローカルテーブルを参照します。ユーザーは新しいテーブルに対する書き込み権限を付与されるため、データベースを変更することによって本来付与されないはずの権限を取得できるようになります。