一般而言，Direct Open SQL 寫入操作 (插入/更新/修改/刪除) 是不良的作法，應予以避免。這些更新會破壞系統的完整性與安全性，因此應禁止。



Direct Open SQL 寫入操作還容易發生錯誤，可能導致非預期的系統行為。在 SAP 中，需要小心的一些問題包括：

- SAP 建議使用「更新統合」技術確保 SAP LUW (工作的邏輯單元) 中可能跨多個資料庫 LUW 的資料完整性。直接修改表格項目而不更新統合可能使 SAP 交易處於不一致的狀態。

- Direct Open SQL 寫入操作只設定資料庫級別的鎖定，而略過 SAP 應用程式鎖定。這可能導致鎖死和資料損壞。

- Direct Open SQL 寫入操作略過應用程式內的 SAP 授權檢查。

- 在使用標準機制寫入表格項目、編輯檢查、稽核路徑時，相依的更新 (例如變更文件) 全部會正確執行。而使用 Direct Open SQL 寫入操作時不是這樣。

在啟動程式權限或 AUTHID CURRENT_USER 封包中，識別碼會先針對目前使用者的結構進行解析。如果程式碼的定義碼無法明確說明識別碼屬於哪一種結構，將會造成意外的行為。

範例 1：下列程式碼會在權限表格中查詢使用者，檢查使用者是否擁有執行操作的權限。大多數使用者只能讀取 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 表格，資料庫將會解析識別碼以參照本機表格。接著，使用者會擁有新表格的寫入權限，並可修改表格以取得原本沒有的權限。