two DOA 3.4.6 nested CDS bugs

[krome]

I have identified two bugs in the DOA source in relation to updating linked TOracleDataSets using standard "nested" clientdatasets in a remote tier. I searched the forum here and did not see either problem previously mentioned.

First bug:

TOracleDataSet does not override and implement the logic for the TDataSet.GetDetailLinkFields() method. This method is (apparently) used to append additional metadata to a provider's outgoing CDS datapacket. The metadata defines the relational linking between master and detail, and is used in the TClientDataSet to propagate the current master record key values to appended detail records automatically. When this method is not implemented, linking metadata is not sent to the TClientDataSet, and it therefore is unable to propagate those keys manually.

The only workaround (short of patching DOA source) is to manually assign the detail record key values in a client-side OnNewRecord event for the detail dataset.

Second bug:

TOracleDataSet.EnableMasterFields() method is marking fields involved in master-detail links as "read-only" at runtime. In the context of a MIDAS remote data module, this is incorrect behavior, as it marks the primary key of the master dataset read-only in the provider metadata sent to TClientDataSet. This causes INSERT operations using TSQLResolver (the default data modification mechanism when using ResolveToDataset=False) to FAIL since the resolver excludes Read-Only fields from INSERT statement generation. There is specific code in this DOA method that causes it to bail out if it determines that it is being run from a TRemoteDataModule. This fixes the problem for projects that directly descend from TRemoteDataModule,... however it does not address the case where a descendant of that class, or more importantly for me, the case where a TMtsDataModule is being used for the same purpose. In this situation, the method will improperly mark master key fields as read-only, which interferes with the later insertion of records using ApplyUpdates.

I am sure I can fix both of these problems by patching my own copy of DOA, however an "official" patch would be more desireable of course. Is there any plans to release a newer version or revision of DOA, and if so - can fixes for these two problems be addressed in such a patch/upgrade?

BTW - we still use Delphi 5 Enterprise here, and no plans to upgrade compiler in near future.

Keith Rome
ZC Sterling, Atlanta

 

[Marco Kalter]

First bug:

The copying of the master fields is performed by the detail TOracleDataSet.

Second bug:

This is fixed, and will be part of the next official patch release.

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

 

[krome]

In regards to item #1: I understand how TOracleDataset copies the values to detail datasets, however this only functions when using live datasets. In a MIDAS scenario, where the datasets are nested and ResolveToDataset is False, its the TClientDataSet that actually becomes responsible for this task. And it cannot perform the cascading of keys without the extra metadata supplied in the GetDetailLinkFields() method. All this method does is populate a TList of Master Fields (just puts TField entries in there), and a TList of Detail Fields (same - just TFields). The VCL source for TQuery shows how they do it for BDE datasets using the TDataSource... it shouldnt be hard at all to implement this method for DOA I would assume (given the existence of MasterFields and DetailFields properties).

If necessary, I can email an example of the difference the implementation of this method has on the structure of data packets, and how it affects the cascading of the key fields.

Is the upcoming patch due soon? If not, is there a chance I could get a code snippet of the fix for the second bug listed? I would rather use your fix than a "home-grown" patch if at all possible, but my timeframe for fixing these issues is very short.

I am in the process of converting old BDE-based MIDAS application servers to DOA-based MTS components, and the sooner I can get a patch for these two issues, the better. Due to deployment issues with the client tier (which contains the TClientDatasets), I would prefer to fix both of these problems in the DOA code used in our application servers rather then fix them with hacks/modifications on the client end.

Feel free to email me at keith.rome@zcsterling.com if you can send me code to patch one or both of these problems.

Thanks,
Keith Rome
ZC Sterling

 

[krome]

Well - I went and "patched" my DOA source with these changes, please consider including them (or some variation thereof) in the next official patch/release. These two changes correct both bugs.

OracleData.pas:

Near the top of procedure TOracleDataSet.EnableMasterFields:

replace

if (Owner <> nil) and
   (Owner.ClassParent <> nil) and
   (Pos('REMOTEDATAMODULE', UpperCase(Owner.ClassParent.ClassName)) > 0) then Exit;

with

if (Owner <> nil) and
   (Owner.InheritsFrom(TRemoteDataModule) or Owner.InheritsFrom(TCRemoteDataModule)) then Exit;

For this to work, you also need to add the unit "Databkr" to implementation uses clause, which will in turn add a package requirement for MIDAS when the DOA package is recompiled. Perhaps there is an easier way to do this without forcing the package reference.

Add the following public method to TOracleDataSet:

procedure TOracleDataset.GetDetailLinkFields(listMasterFields,
  listDetailFields: TList);
begin
  listMasterFields.Clear;
  listDetailFields.Clear;
  if Assigned(Master) then
  begin
    Master.GetFieldList(listMasterFields, MasterFields);
    GetFieldList(listDetailFields, DetailFields);
  end;
end;

You will of course need to forward-define the method in the class interface at top of file too.

Please let me know if these fixes can be implemented (or what other changes would go in that fixes the problems in a better way), and also how soon I could get an "official" patch including these fixes and any others that are waiting out there.

Keith Rome
ZC Sterling, Atlanta

[This message has been edited by krome (edited 26 February 2003).]

[This message has been edited by krome (edited 26 February 2003).]

 

[Marco Kalter]

Thanks, we'll look into this.

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