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…
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?
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?
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).
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
begin
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
TDARemoteDataAdapterRequest(aRemoteRequest).SetupDefaultRequestV3;
exit;
end;
end;
other 5 methods should be handled manually like we done in SetupDefaultRequestV3, i.e. something like
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?
I think you are missing my question.
My questions are
Did this work in build 1489?
Why did you change the functionality? The new versions are less useable IMO.
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.
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.
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.]
program RODLConvert;
{$APPTYPE CONSOLE}
{$R *.res}
uses
uROCOMInit,
SysUtils,
uRODL,
uRODLToXML,
uXMLToRODL;
var
lib: TRODLLibrary;
begin
if FileExists(ParamStr(1)) then begin
lib := LoadLibraryFromXml(ParamStr(1));
RODLToXMLFile(lib, ParamStr(1), false);
lib.Free;
end
else begin
writeln('usage:');
writeln('RODLConvert file.rodl');
end;
end.
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 RemObjects_user.inc for keep changes from prev step
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}