Las operaciones de escritura de Direct Open SQL (Insertar/Actualizar/Modificar/Eliminar) son, en general, poco recomendables y deben evitarse. porque minan la integridad y seguridad del sistema.



Además, las operaciones de escritura de Direct Open SQL son propensas a errores y pueden provocar comportamientos inesperados del sistema. Algunos de los problemas a los que se debe prestar atención en SAP son:

- SAP recomienda el uso de las técnicas "update bundling" (unión de actualizaciones) para asegurar la integridad de los datos dentro de una LUW (unidad lógica de trabajo) que tal vez abarque varias LUW de bases de datos. Las modificaciones directas en las entradas de tabla sin "update bundling" (unión de actualizaciones) pueden dejar la transacción SAP en un estado incoherente.

- Las operaciones de escritura de Direct Open SQL solo establecen los bloqueos de nivel de base de datos y omiten los bloqueos de la aplicación SAP. Esto puede dar lugar a interbloqueos y datos dañados.

- Las operaciones de escritura de Direct Open SQL omiten las comprobaciones de autorización SAP dentro del programa de aplicación.

- Cuando se usan mecanismos estándar para escribir entradas de tablas, comprobaciones de edición, pistas de auditoría, actualizaciones de dependientes (como cambiar documentos, por ejemplo) se ejecutan todas correctamente. Esto no sucede así cuando se utilizan operaciones de escritura Direct Open SQL.

En los derechos de un invocador, o paquete AUTHID CURRENT_USER, los identificadores se solucionan en primer lugar según el esquema del usuario actual. Esto puede provocar un comportamiento inesperado si el definidor del código no expresa explícitamente a qué esquema pertenece un identificador.

Ejemplo 1: El siguiente código comprueba si un usuario tiene permisos para realizar una acción mediante la búsqueda del usuario en una tabla de permisos. La mayoría de los usuarios solo tendrán acceso de lectura a SYS.PERMISSIONS y no podrá modificar los permisos definidos.

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

Si el usuario que llama la función check_permissions define una tabla PERMISSIONS en su esquema, la base de datos decidirá que el identificador haga referencia a la tabla local. El usuario podría tener acceso de escritura a la nueva tabla y podría modificarla para obtener los permisos que de otro modo no tendría.