Service ancestor can not (always) be found in RODL

hi EvgenyK,

question is if the latest release is still supposed to be DA3 compatible, cause we simply can’t modify all tables to DA4 at this moment, but we do want to move to the latest release…
if it ain’t DA3 compatible anylonger, we would like to know what changed and what is needed to get things working again, with the least effort possible…

secondly, what is the roadmap for DA3 compatibility (if so)… cause we really need to plan the migration if we are forced to…



it should be compatible with DA3
at least we didn’t do any breaking changes

well for us it’s not compatible at this moment…
so we need to clear this out, we are blocked at this moment since we moved to D11…
how do we proceed from here?


DA3 became outdated 15 years ago so I think, you should finally migrate from DA3 to DA4.
I can recommend to read DA26 - Upgrading to Data Abstract 4.0 for Delphi.pdf (71.4 KB) article.

I am busy with the sample application that illustrates the issue.
I notice I cannot use the RO RAD studio plugin to create to DA client application for the DA3 service.
Is this expected or a bug?

FYI: Creating the strongly typed sources also gives an error

FYI: This last issue is resolved by restarting the XE11.1 IDE

Attached you’ll find a test server and client which illustrates the issue.
Only the DA3 test is implemented.
You have to rename C:\Program Files (x86)\RemObjects Software\Data Abstract for Delphi\Source\Legacy\DataAbstract3.rodl to trigger the error (or run the exes on another PC). (705.4 KB)

Can this issue be addressed with priority please


this is as expected. that wizard is .NET based.
Data Abstract for .NET supports only DA4 because Data Abstract for .NET was created after DA3 became outdated so it knows nothing about DA3.


I understood this issue.
only 4 methods of DAService can be handled automatically:

     if not Assigned(lOperation) then
       if (lService.Ancestor = 'DARemoteService') and (aRemoteRequest is TDARemoteDataAdapterRequest) then begin
         if (aRemoteRequest.MethodName = 'GetSchemaAsXML') or
            (aRemoteRequest.MethodName = 'GetDatasetData') or
            (aRemoteRequest.MethodName = 'UpdateData') or
            (aRemoteRequest.MethodName = 'GetDatasetScripts') then begin

other 5 methods should be handled manually like we done in SetupDefaultRequestV3, i.e. something like

procedure TDAGetScriptsRequest.SetupDefaultRequestV3;
  OutgoingTableNamesParameter := Params.Add('DatasetNames', rtString, fIn).Name;
  IncomingScriptParameter     := Params.Add('Result', rtString, fResult).Name;
  MethodName := 'GetDatasetScripts';
  Default := false;

ofc, if you don’t use them, you can just skip them

Why are we running into this issue? Is the behaviour change intended? For me it is very poor design that the runtime code requires a development time RODL file.
What is the rational after this functionality change?


You have chosen this design of client application.

btw, why you can’t have pre-configured TRODynamicRequest for the rest of methods of TDAService?

I think you are missing my question.
My questions are

  1. Did this work in build 1489?
  2. Why did you change the functionality? The new versions are less useable IMO.
  3. Are you going to support the old behaviour? Revert the changes?

I do not quite understand what your last question is.
We are sharing remote data adapters for multiple DA tables that can have different methods. This is historic code, I cannot tell you much more about it.


I don’t see any changing in processing or generation of RODL-based services since .1489 (it was released Sep 10, 2020).

we have changed generation of CodeFirst-based services after .1489.
You have tried to apply

{$UNDEF RO_RTTI_Support}
{$UNDEF CodeFirst_Use_RODL_Uses}

for disabling those changes but this change does nothing from your words.

I don’t see any breaking changes in our code, as a result I can’t revert it.

as a cheap workaround, I can suggest to per-initialize 9 dynamic requests for members of TDAService in designtime.
later you can assign them to aRemoteRequest in case DARemoteService is detected as ancestor.

FYI 1: The workaround seems to work
FYI 2: DA4 suffers from the same issue


I think I have another workaround for you.
How do you build your server - via IDE or via cmdline?

At present it is built via IDE as we still have some issues with the commandline build
[Note:Contrary to the deleted post the workaround seems to work. I am still testing the application.]


try to use this workaround:

  • compile this app:
program RODLConvert;


{$R *.res}


  lib: TRODLLibrary;
  if FileExists(ParamStr(1)) then begin
    lib := LoadLibraryFromXml(ParamStr(1));
    RODLToXMLFile(lib, ParamStr(1), false);
  else begin
    writeln('RODLConvert file.rodl');
  • execute

RODLConvert OffServerLibrary.rodl

as a result, all services from used RODLs will be added to your main RODL.

  • add {$UNDEF CodeFirst_Use_RODL_Uses} to for keep changes from prev step
  • [optionally] launch C:\Program Files (x86)\RemObjects Software\Build\install_DA.cmd
  • rebuild your server
  • retest client

Note: you should relaunch RODLConvert after each updating your RODL in Service Builder.

so the generated rodl is changed in the latest releases?


Service Builder: code is related to saving RODL wasn’t changed for 10 +years

Library: Only generation of RODL for CodeFirst services were changed. but it can be disabled via {$UNDEF CodeFirst_Use_RODL_Uses} or {$UNDEF RO_RTTI_Support}