With EDB replication various types of error can occur. EDB usually gives good error messages relating to replication updates failing, for example details such as the Table-name of the update that has failed.

My understanding is that EDB Replication basically runs "line by line" adding updates to the database, and does this in a discrete transaction which it can cancel if any update fails.

When an update fails, it should be possible to return the data for the failing line, particularly the "Key Data" which shows the primary key of the line causing the issue.

This would be hugely useful with updates of many thousands of lines, where just one line might be causing an error, and identifying this line and running a small update on the database might then allow the replication to continue.

Adam,

<< With EDB replication various types of error can occur. EDB usually gives good error messages relating to replication updates failing, for example details such as the Table-name of the update that has failed.

My understanding is that EDB Replication basically runs "line by line" adding updates to the database, and does this in a discrete transaction which it can cancel if any update fails.

When an update fails, it should be possible to return the data for the failing line, particularly the "Key Data" which shows the primary key of the line causing the issue. >>

ElevateDB *does* include the primary key values when there is a primary key constraint violation, but such an exception/error message will only surface if you don't have any ERROR LOAD UPDATE triggers defined for the table.  In such a case, the triggers will get executed instead of the exception being raised, and you can use these functions to get/log any information:

https://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ERRORCODE
https://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=ERRORMSG

Tim Young
Elevate Software
www.elevatesoft.com

Tim

Thanks for this, you are right, my database does have "on update error" triggers, so that is blocking the raising of an error that includes an ID.

My request is a bit more general, rather than an exception, it would be great to log errors (including Key IDs) to some form the Configuration LogEvents table, even if an On Update Error trigger exists.

Load Updates processes tend to happen in Jobs on servers, so it is great to be able to look through a log after the update has run to figure out what has happened.

Alternatively I guess I could add an exception to my On Update Error trigger, and then the message from this exception would be automatically added to the LogEvents table, is that right?

I don't want to do this, if adding the exception would "stall" the JOB. It is important that the updates process continues to run.

Adam,

<< Alternatively I guess I could add an exception to my On Update Error trigger, and then the message from this exception would be automatically added to the LogEvents table, is that right?

I don't want to do this, if adding the exception would "stall" the JOB. It is important that the updates process continues to run. >>

Yes, raising an exception will cause the loading of the updates to terminate (and roll back), so don't do that.

What you really need is a way to log user-defined information to the logged events, which has been on the enhancements list for a long time.  I'll see if I can get it into the next build.

Tim Young
Elevate Software
www.elevatesoft.com