All events for one transaction are returned immediately. Each transaction is returned in full at the time of the commit. Logreader returns full committed transactions in the order that they are committed to the log. Overlapping transactions are returned transaction by transaction.

Operations in the trigger action part are logged as normal user operations. Write operations in triggers are logged when they are executed; before-triggers are logged before user data operation, and after-triggers are logged after user data operation.

Operations that result from cascading referential actions are logged as normal user operations. Cascading operations are logged after the actual user data operation.

For DDL operations, Logreader returns a special DBE_LOGREADER_LOG_REC_DDL record that contains the original SQL statement.

When a log read is started from SYS_LOG, the read goes first into catchup mode. Catchup mode means that the log read start position is searched from the log and the read is then started from that position. When a log read reaches the end of the current log, it starts to read live data. In live mode, transactions are returned as they are executed.

When several instances of Logreader are used, each Logreader has its own data mode.

In live data mode, the cursor returns every second even if there is no data available. In that case, the FLAGS field in the SYS_LOG table is zero.

Although a primary key is not mandatory for tables, system-generated, internal, and hidden primary key values are not returned through the Logreader.

If a primary key is not defined, you must decide how rows are identified when you design your database.

HotStandby (HSB) is supported and the log file contents and log address are compatible between primary and secondary servers. If the log is read from the primary server and there is a failover, a new read from SYS_LOG can be started by using the last LOGADDR that was received from the original primary server.

The log can also be read from the secondary server. This can useful for load balancing reasons.

If the server can generate log records faster than the client can read, throttling can occur. This means that user transactions that write to the server are slowed down to make sure that Logreader is not too much behind the live data. The LogReader.MaxSpace parameter can be used to control the buffering after which throttling can occur, see LogReader section.

Applications that start a read but then stop reading can cause the server to stop.

If the application that uses Logreader is stopped or terminated for a long time, the log maximum size might be reached. In such a case, no error message is produced. Also, the position stored by the application for catchup is not available any more and the effort to catchup fails.

Administrator rights are needed to access the SYS_LOG table, to add tables to a partition, or to remove tables from a partition.

The log reading can be stopped at any time. No data is lost even if some undelivered data is left in the log.

The log reading can be resumed without any loss of information as long as the last read position is known. By using the current log position, the application is able to continue reading the log, without any loss of data, upon the next SYS_LOG query. If the SYS_LOG table is accessed without specifying the log position, the reading starts from the live data.

The Logreader can be stopped in the solidDB server by using the following command:

ADMIN COMMAND 'logreader stop'