Baanboard.com

Go Back   Baanboard.com

User login

Frontpage Sponsor

Main

Poll
For ERP LN feature pack upgrade, what method of install are you using?
Installation Wizard into existing VRC
37%
Installation Wizard into new VRC
39%
Manual into existing VRC
3%
Manual into new VRC
21%
Total votes: 38

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:

db.exit.on.norec

stop session if no record was found

db.skip.norec

skip update/delete action if no record was found

db.exit.on.dupl

stop session if duplicates occur

db.skip.dupl

skip update/insert action if duplicates occur

db.exit.on.rowchanged

stop session if record has been changed after delayed lock

db.skip.rowchanged

skip action if record has been changed after delayed lock

db.return.error*

return error code

db.return.norec*

return error code if no record was found

db.return.dupl*

return error code if duplicates occur

db.return.ref.exists*

return error code if reference exists

db.return.ref.not.exists*

return error code if reference does not exist

db.return.rowchanged*

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.

Example

 table   ttiitm001
 db.retry.point()
 SELECT tiitm001.*
 FROM tiitm001 FOR UPDATE
 WHERE tiitm001.item between :item.f and :item.t
 SELECTDO
         ......
         db.insert(ttiitm001, DB.RETRY, db.skip.dupl)
 ENDSELECT

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



0
No votes yet


All times are GMT +2. The time now is 02:44.


©2001-2017 - Baanboard.com - Baanforums.com