Modifying delta server-side on the fly

Data Abstract
21

you can use this code for creating Session:

  Service.RequiresSession := False;
  Service.ClientID := Self.ClientID;
  Service.CreateSession;
  Service.RequiresSession := True;

more correct code: use IROObjectActivation interface, as we do in uDALocalHelpers.LocalServiceAccessHelper_Acquire, but above code is more simply.

22

Ok thanks Iā€™ll take a look

23

Is it possible to re-use or re-attach the same session for the new service Iā€™m creating or do I have to create a new session? Only reason I ask is that, if creating a new one, Iā€™ll have to copy across properties like Roles and any Values I have on the original session.

24

if you pass existing ClientID, no new session will be created.

25

Hmm, it seems to be creating a new session with the same ID. The Service.CreateSession call follows this path:

TRORemoteDataModule.CreateSession
TRORemoteDataModule.GetSession
TRORemoteDataModule.InternalGetSession
TROCustomSessionManager.CreateSession
TROCustomSessionManager.DoCreateSession

This last function calls TROSession.Create(aSessionID), creating a new session with the same ID. Iā€™m obviously missing something here.

26

Using the IROObjectActivation method seems to work fine so Iā€™m going with that.

Unfortunately I then get a failure in TDataAbstractService.UnpackDeltas during the ApplyUpdates call:

DataAbstractService_Impl.TDataAbstractService.UnpackDeltas((TDADelta($7550D74) as IDADelta),$75158F0)
DataAbstractService_Impl.TDataAbstractService.InternalUpdateData((TDADelta($7550D74) as IDADelta),True)
DataAbstractService_Impl.TDataAbstractService.LDA_InternalUpdateData((TDADelta($7550D74) as IDADelta))
uDALocalDataAdapter.TDALocalDataAdapter.InternalApplyUpdates((ā€¦),(ā€¦))
uDADataAdapter.TDABaseDataAdapter.InternalApplyUpdatesAndThrowFailures($9B239A0,$9B22908)
uDADataAdapter.TDABaseDataAdapter.ApplyUpdates((ā€¦),False)
uDADataTable.TDADataTable.InternalApplyUpdates(False)
uDADataTable.TDADataTable.ApplyUpdates(False,False)

The exact failure line in UnpackDeltas is:

If (ExportedDataTables.Count >0) then begin

ExportedDataTables is NIL. Maybe thereā€™s something else I need to initialise?

27

create custom method and call it from 1st service:

procedure TDASampleService.MySetClientID(aClientID: TGuid);
begin
  _OnActivate(aClientID, nil);
end;
28

Ignore the above error, I was inadvertently freeing the service instance by setting IROObjectActivation interface reference to NIL.

29

Think Iā€™m getting there now, thanks again for all the help.

One quick question regarding transactions - if I throw an exception in my AfterProcessChange handler, this is passed back to the client but the transaction is still committed. Surely if an exception is thrown inside any of the BP handlers then the transaction should be rolled back? Or is this controllable somehow?

30

already answered: Modifying delta server-side on the fly

31

Oops my bad, forgot about that.

32

Iā€™m a little foggy on the operation of ReturnUpdateFailureDelta and RaiseExceptionAtError.

The wiki for the former refers to autogenerated BPs but Iā€™m using my own BP components. Does this mean that ReturnUpdateFailureDelta has no effect and I should just set RaiseExceptionAtError on the BPs to True?

I have a problem when I do this. If I set RaiseExceptionAtError to True then it fixes my problem in that throwing an exception inside AfterProcessChange does cause the transaction to be rolled back (ProcessError is also called).

The problem is that, if the update itself fails to apply to the database, for example if I set a required field to NULL, then with RaiseExceptionAtError set to to true, whilst the transaction is rolled back and the error passed back to the client, ProcessError is never called. Iā€™m using ProcessError to log such issues so I need to it be called.

I hit this issue way back when I first started with DA and got around it by setting RaiseExceptionAtError to False so ProcessError would be called, then re-raising an exception within ProcessError after Iā€™d done my logging. If I didnā€™t re-raise the exception inside ProcessError then I got the built-in reconcile dialog which I didnā€™t want so this was the only way I could see of doing what I wanted.

Iā€™m also not sure how ReturnUpdateFailureDelta fits into this scenario. The wiki refers to autogenerated BPs whereas Iā€™m using my own BP components so does this option not apply?

33

Hmm, seems to be working correctly now with RaiseExceptionAtError set to True, even if I throw my own exception. Not sure what was going on before but seems to be working now.

34

Aha, I think I see whatā€™s happening here (this is with RaiseExceptionAtError = True)

If I just thrown an exception at the end of my AfterProcessChange handler, then the transaction is rolled back and the exception passed to the client, just as I want and would expect.

If I add the code to AfterProcessChange to make the secondary changes I need, so creating a service manually and using the same connection, then this works fine with one difference - the manual exception I throw afterward doesnā€™t rollback the transaction.

Whatā€™s happening is that the ApplyUpdates call on the secondary table is committing the original transaction, so if I subsequently throw an exception in my original AfterProcessChange handler, itā€™s too late, the transaction has been committed.

This obviously isnā€™t going to work properly as, if my original delta had updates for several rows, then the first of these required changes in the secondary table, then the transaction would be committed by the secondary table updates, so when the second row in the original delta is processed, the transaction is no longer active.

What I need is for the secondary service to do its work within the original connectionā€™s transaction but not commit or roll it back. If an error occurs during the secondary processing then this should be passed back up to the main processing which can then rollback the overall transaction and stop processing the rest of the main delta.

35

ReturnUpdateFailureDelta only inits BP.RaiseExceptionAtError for autogenerated BP. if you have some BP on form, you need to set their RaiseExceptionAtError property manually.

note: you need to set ReturnUpdateFailureDelta/RaiseExceptionAtError values for 2nd service too.
note2: RaiseExceptionAtError and ReturnUpdateFailureDelta has opposite values, i.e.

BP.RaiseExceptionAtError := not DAService.ReturnUpdateFailureDelta;
36

Cool thanks, think Iā€™m nearly there (but then Iā€™ve thought that before haha)