BusinessEntity - strange behaviour with Create and Update

Posted by tomas.kucera on 19-Apr-2016 07:01

Hi there,

I am "playing" with BusinessEntity and am experiencing strange behaviour with Create and Update.

1. Update - cannot update field(s) that is(are) part of primary unique index - this looks like a limitation and I can somewhat live with it but I guess it is something that is doable and could be implemented.

2. Create - I have id field as character (that is primary unique indexed) with a create trigger that assigns generated id to it and then a couple of character fields ... two of them are part of unique index. When I create a record in TT with all the fields (except for the id field) and call CreatedsXXX, it runs without any errors (I even check ERROR-STATUS) but the record is not being created.

Any idea?

Thanks ... tom.+

All Replies

Posted by smat-consulting on 19-Apr-2016 08:23

Haven't played with Business Entity at all, but the symptom I encountered frequently when using triggers. Somehow the error-status gets lost when the transaction is being backed out when a non-unique (or other trigger error) is encountered.

Every transaction in my programs has an ON ERROR UND, RETRY on the transaction block, includes an IF RETRY THEN ..< error handling> ELSE DO: <actual transaction logic> END. , and within the transaction, just before the end also includes a VALIDATE <table> NO-ERROR. IF <all kinds of error condition checks> THEN: ... UNDO, RETRY. END.

I'm working with WebSpeed, so no errors are displayed on the screen - obviously. My error-handling writes a message to the message-queue, the content of which is then sent to the browser upon finishing the request. With the above logic I get all the messages and always at least know there was a problem and the transaction is backed out.

Heads-up, though: when unique index is attempted to be broken (or some other low-level DB stuff) you get only a retry but no error-status nor return-value from the trigger. In that case, all you have is an error-number in  _msg(1), when RETRY is executed...

I was thinking about adding a unique-index verification in the trigger, but haven't found the time to play with that...

Posted by tomas.kucera on 19-Apr-2016 09:16

I actually think it has nothing to do with the trigger. It just does this:


That I expect is very rare to be blown out. ;)

Plus I also removed the trigger and it does the same ... actually does nothing. :(


Posted by Mike Fechner on 19-Apr-2016 09:21

I hope your ID field is case-sensitive - as the BASE64-ENCODE is only UNIQUE when used CASE-SENSITIVE.

Posted by Peter Judge on 19-Apr-2016 09:30

Why do you BASE64-ENCODE() the GUID? You can simply use field_id = GUID and let the transport/JSON deal with encoding issues.

Posted by tomas.kucera on 19-Apr-2016 11:14

Mike, very good point!

Posted by tomas.kucera on 19-Apr-2016 11:15

Peter, the code is ABL DB trigger, that is why I am base64-encoding.

Posted by on 19-Apr-2016 11:30

that’s because looks like Tom is not using GUID(STRING) but GENERATE-UUID (RAW) so he felt that should be base64-encoded… just switch to GUID, no need to bother about case-sensitive with that

Marian Edu

Acorn IT 
+40 740 036 212

This thread is closed