Go Back

User login

Frontpage Sponsor


Google search

For ERP LN feature pack upgrade, what method of install are you using?
Installation Wizard into existing VRC
Installation Wizard into new VRC
Manual into existing VRC
Manual into new VRC
Total votes: 49

Baanboard at LinkedIn

Reference Content

Error handling
By patvdv at 26 Feb 2008 - 21:56

Error handling

There are three broad categories of errors. Errors generated by the operating system (numbers 1 - 99), errors generated by the Baan database system (numbers 100 - 900) and errors generated by the underlying RDBMS (numbers 1000 and upwards ). In case of an RDBMS error, the actual (native) error code can be obtained by substracting 1000 from the Baan error code. See Errors.

To keep the messages to be sent over the network to a minimum, database actions and messages must be buffered as much as possible. Buffering updates means that as few updates as possible return error codes. These, after all, cause a rollback and a return to a retry point. It is therefore possible to allocate flags to updates indicating the action to be taken by the system when a database action fails. The database server will then no longer execute a rollback, but a follow-up action.

Fatal and non-fatal errors

There are fatal and non-fatal errors. Fatal errors terminate the session. Non-fatal errors are those that are temporary (for example, elocked), or that are caused by a multi-user situation (for example, a record is deleted by two processes, one process receiving enorec). Non-fatal errors cause the program to go back to the last retry point. If this is missing, the session is terminated. Fatal errors are errors caused by:

  • Errors in the (logical) database (for example, enotable, eddcorrupt, enoserver)
  • Errors in the underlying (R)DBMS (for example, ebadkey)
  • Program errors (for example, enotinrange)

The following error codes result in a return to the retry point:

elocked (107) record is locked
eflocked (113) file (table) is locked
emlocked (210) record in mirroring is locked
ereflocked (601) reference record is locked
edupl (100) duplicate record
enorec (111) record not present
erowchanged (201) record modified since last read
eabort (850) rollback in (R)DBMS

The eflag

For a number of errors it is possible to indicate which action the system must carry out when the error occurs. You can add these to a database action with the <eflag>. For example:

 db.insert(table, DB.RETRY [, eflag])
 db.update(table, DB.RETRY [, eflag])
 db.delete(table, DB.RETRY [, eflag])

The following flags are available for eflag:


stop session if no record was found


skip update/delete action if no record was found


stop session if duplicates occur


skip update/insert action if duplicates occur


stop session if record has been changed after delayed lock


skip action if record has been changed after delayed lock


return error code


return error code if no record was found


return error code if duplicates occur


return error code if reference exists


return error code if reference does not exist


return error code if record has been changed after delayed lock

* The program does not return to the retry point.

Note that you can combine flags by using the '+' sign.


 table   ttiitm001
 SELECT tiitm001.*
 WHERE tiitm001.item between :item.f and :item.t
         db.insert(ttiitm001, DB.RETRY, db.skip.dupl)

In this case, the flag 'db.skip.dupl' causes the system neither to go back to the retry point nor return an error code when adding an already existing record.

Related topics

No votes yet

All times are GMT +2. The time now is 22:07.

©2001-2018 - -