Hi,
I have an SDO containing a field which is regularly updated outside of Dynamics. This SDO is the datasource of a heavily used updateable browse. Because of the high frequency of the external updates, Dynamics often refuses manual updates to (other) browse fields on account of the modified database value in the background ("Update cancelled" etc).
I realise this behaviour is expected and usually even desirable, but in this particular case I want to tell my SDO to ignore this particular field. I can't find a way to do this.
The message is triggered in function bufferCompareDBToRO in query.p, where a BUFFER-COMPARE between RowObject and the database record occurs. There is even an exclusion list passed into that function, but there does not seem to be a way to add other fields to that exclusion list.
Does anyone have any ideas?
Thanks very much,
Robin.
You could probably override bufferCompareDBToRO in your SDO and add the field to the exclusion list parameter before you call SUPER (The parameter can/will have a list of fields when called in an SDO with more than one table). Keep in mind that bufferCompareDBToRO only is called in "difficult" cases when the ABL BUFFER-COMPARE cannot be used, which is when the SDO has CLOB fields or is mapped to arrays in the database.
A more general approach could be to completely override (copy and rewrite and not call super) compareDBRow. This could also allow you to add your own exclusion list property that you could use in the override.
You can also turn off the optimistic locking completely by setting CheckCurrentChanged to false in the SDO. (rather drastic)
Thanks for the quick reply, Havard.
Overriding bufferCompareDBToRO works perfectly. Simple, but it didn't occur to me. I had a temp fix in place where I forced an update of the RowObject field, which also did the job, but that required additional database access, obviously (not that the overhead was that dramatic).
It does not look like bufferCompareDBToRO is only called for difficult cases, by the way. The vanilla BUFFER-COMPARE all the way at the bottom of the function is the one being executed for me - not the CLOB- & array-related code above. Just as a side note.
As for your compareDBRow suggestion: I did not test it, but I prefer not to fully bypass Dynamics' SUPERs if I can avoid it.
And turning off optimistic locking does indeed sound a bit over the top - but good to know the option exists - I had not come across CheckCurrentChanged yet.
Thanks once again,
Robin.
Thanks for your feedback.
Notes taken.
My main concern was that the bufferCompareDBToRO might not always be called and that a general customization thus might require overriding compareDBRow.