Session restrictions

The following restrictions exist within a UDR with respect to the session:
  • Session-connection restrictions

    A UDR runs within an existing session. It can only obtain a connection to this session after a client application has already begun the session. However, a UDR can obtain more than one connection to the session.

  • Cursor restrictions
    • Cursors opened in one session are only visible in the context of that session. Cursors defined on one UDR are not visible in other UDRs. Therefore, multiple UDRs can use the same cursor names.
    • A cursor opened in a session persists until an mi_close() or an mi_drop_prepared_statement() function, or until the end of the statement that called the UDR (if mi_close() was not called). Therefore, cursors last across routine invocations.
  • Database restrictions
    • A UDR cannot connect to a remote database server.
    • A UDR uses the default database, which the client application has established. However, it cannot change the database.
  • Table restrictions

    The scope of temporary tables created in a logging database is the current session. Temporary tables created in a database that does not use logging or with a CREATE TABLE statement that includes the WITH NO LOG clause persist until beyond the CLOSE DATABASE statement.

  • Constraint restrictions

    Violations that are associated with the execution of the UDR are added to a violation temporary table. Therefore, if the SET CONSTRAINTS statement sets the constraint mode to IMMEDIATE, constraint checking is done per statement. Otherwise, constraint checking is deferred to the time when the transaction is committed. If the constraint mode is set to IMMEDIATE, the constraint is checked after each statement in the UDR. If you want per-UDR constraint checking, change the constraint mode to DEFERRED at the beginning of the UDR and back to IMMEDIATE at the end of the UDR.