FWD » Core Development » Database

Although we generally have full support for ERROR-STATUS:ERROR, the ERROR attribute also exists for buffer, dataset and temp-table. All three have some level of runtime implementation already. The gap marking reports support as conversion full and runtime partial. I know that COMPILER:ERROR is just a runtime stub, but there is also this comment:

<rule>attrs.put(prog.kw_error   , rw.cvt_lvl_full       | rw.rt_lvl_partial)</rule> <!-- no runtime for DataSets -->

I know there is really runtime there for datasets, but on the other hand there are some specific details in the 4GL docs which I'm not sure if we support fully:

• Indicates an error from a FILL() or SAVE-ROW-CHANGES().
• Is cleared when the object's before-image records are removed in ACCEPT-CHANGES(), EMPTY-DATASET(), FILL(), MERGE-CHANGES() and REJECT-CHANGES().
• Ignored (or lost?) if the before-table is not NO-UNDO.
• "For the Buffer object handle, this attribute causes the row to be backed out rather than merged with the MERGE-CHANGES method or the MERGE-ROW-CHANGES method."
• Serialized in appserver calls.

And there is this note:

The ERROR attribute is writeable for a ProDataSet object, a Temp-table object, and a Buffer object. You can set the ERROR attribute programmatically in order to manage the application response to errors. For example, you might set the ERROR attribute to FALSE in order to ignore all errors that might be returned for a statement using the NO-ERROR option. However, note that manually setting this attribute has no affect on ABL error management. Thus, if you set the ERROR attribute to TRUE, the AVM does not also raise the ERROR condition.

Do we support all of the above?

Ovidiu: What is the status of this one?

• manually, when the ABL programmers consider necessary;
• set to true when a buffer.fill() and dataset.fill() encounter errors;
• set to true when SAVE-ROW-CHANGES encounters an error;
• the flag is cleared (set to false) when merge-changes, reject-changes and accept-changes are successful;
• also cleared when emptied.

These seems to match the description you found. But need testing to confirm the exact conditions. The only thing that I cannot confirm is whether it is "Serialized in appserver calls.". I think not, but it should not be difficult to add.

Since #6414-3 we have the Errorable interface which groups together all error attributes, regardless of object type (no more incorrect unwrapping).

• behaviour of MERGE-ROW-CHANGES method is not influenced by this flag (although the MERGE-CHANGES is);
• not serialized in DatasetWrapper and table serializers (json/xml).

It should take a few hours to check if these need and do the implementation, if the case.

Do we have tests in xfer test suite for this attribute?

Ovidiu Maxiniuc wrote:

Do we have tests in xfer test suite for this attribute?

I am not aware of any. Marian, do you have an idea?

Eric Faulhaber wrote:

Ovidiu Maxiniuc wrote:

Do we have tests in xfer test suite for this attribute?

I am not aware of any. Marian, do you have an idea?

It doesn't seems to have much but I can easily add a few more test methods in the existing one, for serialisation this one is definitively being serialised but I think the only thing we've tested on this area was how the data is being passed along, and serialised for rest/soap.

Code review 6414a/14806-7:

The changes to the DataSet* classes look fine. I am not as familiar to the functionality in BufferImpl.mergeRowChanges, so it is difficult for me to review this method. There are a few concerning things, however.

1) The early out:

      if (changesBuf.rowState().isUnknown() || changesBuf.rowState().intValue() == Buffer.ROW_UNMODIFIED)
      {
         return true; // ??
      }

Is this a success condition? The row being unmodified seems like it should be ok, but is it ok if the row state is unknown? The comment // ?? is a little unsettling.

2) Throwing a RuntimeException (line 10563) upon catching PersistenceException will cause an abend. This is not new, but is there a more graceful way to fail?

Eric Faulhaber wrote:

Code review 6414a/14806-7:

Thank you for the review. A second pair of eyes are always better when we talk programming.

1) The early out:
[...]
Is this a success condition? The row being unmodified seems like it should be ok, but is it ok if the row state is unknown? The comment // ?? is a little unsettling.

This is normal. No changes means nothing to handle. I added a comment describing the situation.

2) Throwing a RuntimeException (line 10563) upon catching PersistenceException will cause an abend. This is not new, but is there a more graceful way to fail?

I overlooked that in my first commit. I am not aware what error should we throw here because I do not know what OE would do in this case, if they encounter a similar processing. This was the cause of initial solution. I picked the most appropriate: 11926 Found unexpected error while merging changes. I think this is fine until we find the true error in this case.

Branch 6414a updated, rebased and pushed as r14827.

I think there are very few places in customer projects which are affected by the changes in this branch. The fwdtests on a very large application customer application should do it. I think that is of the few to use the merge[Row]Changes if not the only one.

Task branch rebased and pushed up as r14831.

The task branch was rebased to latest trunk. The current revision is 14861.
I also test with a large customer application and no regression was revealed.

You can merge to trunk now.