Hi all -

I am new to DOA and need some advice on posting updates via tdatasetprovider..

I have a nested structure (TDatasetFields) wired up on the server side using a single TDatasetProvider and several M/D TOracleDatasets. Some of the datasets read tables, and some read non-updateable views.

When I post the single structure from the Client, I get a datset not open error when trying to resolve the first child dataset on the server. I am using ResolveToDataset=True.

Question - is this the wrong strategy to be using? Should I turn off ResolveToDataset and process each delta in the TDatasetProvider.BeforeUpdateRecord event?

here is how I was doing this prior to DOA:

procedure TlwdmIVE.dspIVE_HDRBeforeUpdateRecord(Sender: TObject;
SourceDS: TDataSet; DeltaDS: TCustomClientDataSet;
UpdateKind: TUpdateKind; var Applied: Boolean);

if DeltaDS.datasetfield = nil then begin
// process the master dataset
end

else if DeltaDS.datasetfield.fieldname = (ChildDSName here) then begin
// process the named child dataset
end

etc.


I was hoping to allow DOA to process all the tables, then intercept control (via ApplyRecord event) to handle the views, but perhaps this won't work with a nested structure?

thanks for any advice -

david buitenveld

For nested structures you should set ResolveToDataSet to False. See the 3Tier demo project for an example. I'm not sure how this relates to your BeforeUpdateRecord handler though.

------------------
Marco Kalter
Allround Automations

This is what I suspected.. When ResolveToDataset is false (as I understand) you have a couple of ways to proceed for custom updates (e.g. read only views).. 1) intercept control at the OnUpdateData which gives you access to the entire delta packet.. you could, for example, send this off through an xml-rpc call to a java program running on the Oracle box.. 2) intercept control via the BeforeUpdateRecord event which gives you control at each dataset.. (once for the master, once for each child below the master, etc).. this is where I usually intercept and either employ a custom resolver strategy or pass to a stored proc.

thanks for the info -


david buitenveld