DAOGen - can I avoid rollback when '0 rows found' ?

[mapleleafblue]

Hi,

The attribute isMST is exposed in the Business Layer as a parameter, allowing us to programmatically control the commit. This is a good thing.

However, the associated attributes RequiredRows and RollbackWork are not exposed, with the result that a SelectRecord() that retrieves no rows will always be regarded as an error and produce a rollback. This is often a bad thing.

Is there some trick that can be used in the Business Layer to override this behaviour?

Regards
Richard

[skybeam]

Originally Posted by mapleleafblue

Hi,

The attribute isMST is exposed in the Business Layer as a parameter, allowing us to programmatically control the commit. This is a good thing.

However, the associated attributes RequiredRows and RollbackWork are not exposed, with the result that a SelectRecord() that retrieves no rows will always be regarded as an error and produce a rollback. This is often a bad thing.

Is there some trick that can be used in the Business Layer to override this behaviour?

Regards
Richard

Perhaps the templates could be edited and the UserClasses regenerated to achieve this effect, which does indeed seem a good thing. Has anyone hereabouts tried this?

[mahjo03]

Originally Posted by mapleleafblue

Hi,

The attribute isMST is exposed in the Business Layer as a parameter, allowing us to programmatically control the commit. This is a good thing.

However, the associated attributes RequiredRows and RollbackWork are not exposed, with the result that a SelectRecord() that retrieves no rows will always be regarded as an error and produce a rollback. This is often a bad thing.

Is there some trick that can be used in the Business Layer to override this behaviour?

Regards
Richard

Can you acheive this by running DAOGen, Clicking on the Options tab, Editing the Custom DataRecord template and modifying the RequiredRows parameter?

[mapleleafblue]

All,

So, from the 2 replies it seems the best bet is to edit a template and
regenerate.

I couldn't find any specific description of how these templates work, but
it seems that this might do the job:-


In the DataRecord template for the SelectRecord() method:

1. alongside the IsMST parameter definition, add 2 lines :

//#GenerateParameter,client,RollbackWork,Integer not null default TRUE
//#GenerateParameter,client,RequiredRows,Integer not null default 1

2. in the PrepareSession() call, change the 'hard coded' RequiredRows=1 and
add in RollbackRequired:

CurMethod.DbSession = CurObject.PrepareSession(
Operation=OP_SELECTRECORD,IsMST=IsMST,
RequiredRows=RequiredRows,RollbackRequired=Rollbac kRequired,
Status=Status


That seems to be it. PrepareSession is already coded to handle the 2 extra
parameters, so what I'm trying to achieve is very nearly there in the
supplied product.

Of course, another option would be to place a new method, based on the
DataRecord SelectRecord(), in the Business Layer (SelectRecord3(??)) but
tailored as per the above. Other changes would be needed because
SendSuperClass() would not be available, so alternative coding for 'thin
client' execution would be needed.

Do any learned members have an opinion on the merits of these approaches?

Thanks

Richard

[skybeam]

All,

After some time spent pondering, and even more testing, here is the solution we have arrived at:

Amend the DataRecord template for SelectRecord() as follows:
a. add 2 parameters:
//#GenerateParameter,client,RollbackWork,Integer not null default TRUE
//#GenerateParameter,client,RequiredRows,Integer with null default 1
b. change PrepareSession() "RequiredRows=1" to "RequiredRows=RequiredRows"
c. add "RollbackWork=RollbackWork" to PrepareSession().

This allows the business layer to control the behaviour of Selecting 0 rows (i.e. RowsRequired=NULL means "don't check the Rowcount"). This can be repeated for DeleteRecord() & UpdateRecord() as required.

It will then be necessary to (re)Generate all classes.

However, this leaves the subtle issue of the _ExistsInDB attribute, whereby SelectRecord() may retrieve 0 rows yet set _ExistsInDB=TRUE. This is because there is an assumption in the underlying error checking that to have reached that point a row must have been retrieved.

To improve on this behaviour it is necessary to make 2 changes to DataAccessObject CheckTransaction(), and one to DataRecordObject CheckSession() methods.

In DataAccessObject CheckTransaction we move the "update the administrative attributes" code from after the commit to before, then make it check the RowCount, as follows:

If (CurObject.IsA(CLASS=DataRecordObject) = True) Then
Record = DataRecordObject(CurObject);
Case Operation Of
OP_INSERTRECORD,
OP_SELECTRECORD,
OP_UPDATERECORD:
{
// !!! - test to set _ExistsInDB=False added March 2010 !!!
If DbSession.RowCount > 0 Then
Record._ExistsInDB = True;
Else
Record._ExistsInDB = False;
EndIf;
Record._HasChanged = False;
}
OP_DELETERECORD:
{
Record._ExistsInDB = False;
Record._HasChanged = False;
}
Default:;
EndIf;

Note: This entails accepting a risk that a failed commit would leave these attributes in a false state.

Finally, in DataRecordObject CheckSession() you will see that the "administrative attributes" are set a 2nd time. This is after the return from CheckTransaction() and so, perhaps, after a commit. We, therefore, comment it out altogether.

Our change is now complete, and the usefulness of the affected methods is now much improved.

HTH
Dave