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.+
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...
I actually think it has nothing to do with the trigger. It just does this:
ASSIGN field_id = BASE64-ENCODE(GENERATE-UUID).
That I expect is very rare to be blown out. ;)
Plus I also removed the trigger and it does the same ... actually does nothing. :(
tom.+
I hope your ID field is case-sensitive - as the BASE64-ENCODE is only UNIQUE when used CASE-SENSITIVE.
Mike, very good point!
Peter, the code is ABL DB trigger, that is why I am base64-encoding.
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