Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: DataSnap changes from XE6 to Berlin


This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 12 - Last Post: Jan 10, 2017 6:31 AM Last Post By: Emanuel Rohani Threads: [ Previous | Next ]
Peter Evans

Posts: 48
Registered: 12/16/01
DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 6, 2016 10:32 PM
Hello All,

I have a working DataSnap Server and Client built in Delphi XE6. (The Client is in FMX.)

I have just upgraded to Delphi 10.1 Berlin. It is running in a new Windows 10 machine.

I can compile and run the Server. I can compile and run the Client.

When the Client runs I get the message "Connection Closed Gracefully".
I have never got this message before!

In the ClientModuleUnit1 is the component SQLConnection1. The message is from the line:-

SQLConnection1.Open;

Thinking that I might have to regenerate ClientClassesUnit1 :-

I right clicked on the component SQLConnection1 and chose menu "Generate DataSnap client classes".

Unfortunately I get the same message "Connection Closed Gracefully".

Have there been any changes from Delphi XE6 through Berlin that might affect my code? Any other ideas?

Regards,
Peter Evans

Peter Evans

Posts: 48
Registered: 12/16/01
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 9, 2016 6:01 AM   in response to: Peter Evans in response to: Peter Evans
This message/s masked an underlying message like:-
'Remote error: VAR and OUT arguments must match parameter type exactly'.

See Quality Portal RSP-14895 : DataSnapServer happen error when DataSnap Method has out Paratemer (sic) in ServerMethod.

In my case the returned parameter is a VAR and not an OUT.

I will try and work on a simple program that reproduces this.

As RSP-14895 states "this bug is very big".

Regards,
Peter Evans
Peter Evans

Posts: 48
Registered: 12/16/01
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jun 14, 2016 12:05 AM   in response to: Peter Evans in response to: Peter Evans
I have now added a test project and screen shot to the Quality Portal issue.

The problem is a fundamental one in calling datasnap.

Regards,
Peter Evans
Mathias Burbach

Posts: 42
Registered: 12/8/99
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 18, 2016 3:21 AM   in response to: Peter Evans in response to: Peter Evans
Hello Peter,

I can confirm that I have the same problem with out parameters in DataSnap & Delphi 10.1 Berlin. It is working in Delphi 10 Seattle.

I checked the source code between the two versions for the call stack when it fails in Delphi 10.1 Berlin:

:7696b727 KERNELBASE.RaiseException + 0x58
System.Rtti.PassArg(???,???,???,ccReg)
System.Rtti.TRttiInstanceMethodEx.DispatchInvoke((($B010A8, Pointer($B482D0) as IValueData, 128, 53376, 67948672, $40CD080, TClass($40CD080), ..., ($40CD080, nil), $40CD080)),(...))
System.Rtti.TRttiMethod.Invoke($40CD080,(...))
Datasnap.DSReflect.TDSMethod.Invoke($40CD080,$6793F20)
Datasnap.DSCommonServer.TDSServerMethod.Invoke($67EA4B0)
Datasnap.DSCommonServer.TDSServerMethodCommandHandler.DbxExecute($67EA4B0)
Datasnap.DSCommonServer.TDSServerConnectionHandler.DbxExecute($67EA4B0)
Data.DBXMessageHandlerCommon.TDBXExecuteMessage.HandleMessage(???)
Data.DBXMessageHandlerJSonServer.TDBXJSonServerInputConnectionHandler.DbxExecute($67EA4B0)
Data.DBXMessageHandlerJSonServer.TDBXJSonServerInputConnectionHandler.HandleDbxRequest
Data.DBXMessageHandlerJSonServer.TDBXJSonServerInputConnectionHandler.HandleNonBlockingProtocol
Data.DBXMessageHandlerJSonServer.TDBXJSonServerProtocolHandler.HandleNonBlockingProtocol
Datasnap.DSTCPServerTransport.TDSTCPServerTransport.DoOnExecute(TIdContextPeer($67A2008) as IIPContext)
...


Starting at the deepest level I can see no differences in
* System.Rtti.PassArg
* System.Rtti.TRttiInstanceMethodEx.DispatchInvoke
* System.Rtti.TRttiMethod.Invoke

But TDSMethod.Invoke has already the first difference between Delphi 10 Seattle and Delphi 10.1 Berlin.

Here is the Seattle code:
procedure TDSMethod.Invoke(MethodInstance: TObject;
  MethodValues: TDSMethodValues);
var
  ParamIndexes: array of Integer;
  Params: TArrayOfVariant;
  I: Integer;
begin
  Params := MethodValues.GetValues;
  SetLength(ParamIndexes, Length(Params));
  for I := 0 to Length(ParamIndexes) - 1 do
    ParamIndexes[I] := I + 1;
  MethodValues.ReturnValue := ObjectInvoke(MethodInstance, FMethodInfoHeader, ParamIndexes, Params);
end;


And here is the Berlin code:
procedure TDSMethod.Invoke(MethodInstance: TObject;
  MethodValues: TDSMethodValues);
var
  RContext: TRttiContext;
  RType: TRttiType;
  Params: TArrayOfTValue;
begin
  Params := MethodValues.GetValues;
  RType := RContext.GetType(MethodInstance.ClassType);
  MethodValues.ReturnValue := RType.GetMethod(FMethodInfoHeader.NameFld.ToString).Invoke(MethodInstance, Params);
end;


The Params variable is different and looks much simpler in Seattle. In Berlin the value of Params[1]: TValue.Kind is tkUnknown. I am not sure if this should be the appropriate kind. To me it looks like a " [Verschlimmbesserung|http://dictionary.reverso.net/german-english/Verschlimmbesserung] ", which is the German work for trying to improve something and at the same time making it worse.

The interesting bit is that this problem does not occur for simple types like Integer or Word, but the more complex types like your TPersonList or my TDataSet will cause the problem in PassArg for the first "complex" data type.

I hope you will an answer on [RSP-14895|https://quality.embarcadero.com/browse/RSP-14895] soon. I have definitely voted for it.

Salut,
Mathias

Edited by: Mathias Burbach on Jul 18, 2016 8:26 PM
Peter Evans

Posts: 48
Registered: 12/16/01
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jul 18, 2016 3:35 PM   in response to: Mathias Burbach in response to: Mathias Burbach
Hello Mathias,
Thank you for your investigation. I did not have Seattle available to do a comparison.
I like the word "verschlimmbesserung" to convey this problem.

I just checked RSP-14895 five minutes ago. There are now 32 votes on this issue. Two (2) hours ago 'beneficiar entidad cooperativa' added 1 screen shot and 2 comments.

Only one (1) hour ago that same person added an issue. This new issue seems to be the same as RSP-14895.

As more than two (2) months have passed since the problem was first reported I have lost hope that it will be resolved.

Regards,
Peter Evans
Frank Staal

Posts: 115
Registered: 12/9/99
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 11, 2016 1:51 AM   in response to: Peter Evans in response to: Peter Evans
I just added a comment as well in the hope that it shakes them awake. Though I doubt it.

I see from the example code that it affects normal DataSnap usage, we get them within the callback system... I am going to try to stringify the JSON structures being passed along the line in hope of working around it.
Peter Evans

Posts: 48
Registered: 12/16/01
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 3:59 PM   in response to: Frank Staal in response to: Frank Staal
I have developed a sample Delphi project group consisting of 4 projects demonstrating how to convert a DataSnap program into one using the mORMot open source technology.
You can find the link to the sample in the following thread.

The subject is :-
Windows FMX Client versus Android FMX Client

Hopefully this direct link will work :-
http://synopse.info/forum/viewtopic.php?id=3418

I am using my methodology to convert a very large DataSnap project.
Frank Staal

Posts: 115
Registered: 12/9/99
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 7:21 AM   in response to: Peter Evans in response to: Peter Evans
I've been messing around with the possibilities in our set of programs in DS callbacks. The set works a bit like a chatroom: app A calls to the MainServer which relays the message to B, B handles it and returns the Result to A via the MainServer. Whether I use NotifyObject, NotifyCallback (either the string or TJSONValue version), implement a TInterceptor or TConverter/TReverter pair, every time the MainServer will throw the VAR and OUT exception...
Frank Staal

Posts: 115
Registered: 12/9/99
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 16, 2016 7:34 AM   in response to: Peter Evans in response to: Peter Evans
I found the original sample which I extended/changed to use as basis for our "chatroom"-imitation in the Samples folder of XE3 (CallbackChannels was the name). The only thing needed to get it to work under Berlin is add the System.JSON file to the uses, after that you can run it.

I started the server, opened a client and connected on ChannelOne with ClientFirst on CallbackAAA and saw myself appear in the Channel Server. Started another one, connected to ChannelOne as ClientSecond on CallbackAAA thereby creating one example of our partyline.

When the Client clicks on "Broadcast to Channel", the message is transported to the other client through the server, when Notify Client is clicked the VAR and OUT message pops up. On the other hand the server can send messages as well, and either clicking on Broadcast Message or Notify Client all succeed...

This corresponds to the current batch of samples, which at most have the server calling back a provided function.
Emanuel Rohani

Posts: 1
Registered: 4/27/00
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Jan 10, 2017 6:31 AM   in response to: Frank Staal in response to: Frank Staal
Frank Staal wrote:
I found the original sample which I extended/changed to use as basis for our "chatroom"-imitation in the Samples folder of XE3 (CallbackChannels was the name). The only thing needed to get it to work under Berlin is add the System.JSON file to the uses, after that you can run it.

I started the server, opened a client and connected on ChannelOne with ClientFirst on CallbackAAA and saw myself appear in the Channel Server. Started another one, connected to ChannelOne as ClientSecond on CallbackAAA thereby creating one example of our partyline.

When the Client clicks on "Broadcast to Channel", the message is transported to the other client through the server, when Notify Client is clicked the VAR and OUT message pops up. On the other hand the server can send messages as well, and either clicking on Broadcast Message or Notify Client all succeed...

This corresponds to the current batch of samples, which at most have the server calling back a provided function.

Has this issue been resolved yet? I have the same problem geting "Var and OUT" message every time I call "NotifyCallback" but "BroadcastToChannel" works fine.
chinaexpressair...

Posts: 1
Registered: 5/19/16
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 25, 2016 5:26 PM   in response to: Peter Evans in response to: Peter Evans
Peter Evans wrote:
Hello All,

I have a working DataSnap Server and Client built in Delphi XE6. (The Client is in FMX.)

I have just upgraded to Delphi 10.1 Berlin. It is running in a new Windows 10 machine.

I can compile and run the Server. I can compile and run the Client.

When the Client runs I get the message "Connection Closed Gracefully".
I have never got this message before!

In the ClientModuleUnit1 is the component SQLConnection1. The message is from the line:-

SQLConnection1.Open;

Thinking that I might have to regenerate ClientClassesUnit1 :-

I right clicked on the component SQLConnection1 and chose menu "Generate DataSnap client classes".

Unfortunately I get the same message "Connection Closed Gracefully".

Have there been any changes from Delphi XE6 through Berlin that might affect my code? Any other ideas?

Regards,
Peter Evans


Any idea on how to resolve this problem?
Any idea on how to resolve this problem?
Peter Evans

Posts: 48
Registered: 12/16/01
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 25, 2016 7:58 PM   in response to: chinaexpressair... in response to: chinaexpressair...
Any idea on how to resolve this problem?

1. You can follow RSP-14895 at Quality Portal.
Unfortunately that issue has not been fixed.

2. You can find an alternative solution.
I am porting my DataSnap code to mORMot.
I have provided a solution for people wanting to port Delphi FireMonkey Windows Clients and Delphi FireMonkey Android Clients.
If you only want to port Delphi FireMonkey Windows Clients then the solution is simpler.

Regards,
Peter Evans
Peter Evans

Posts: 48
Registered: 12/16/01
Re: DataSnap changes from XE6 to Berlin  
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 11, 2016 3:48 PM   in response to: Peter Evans in response to: Peter Evans
I have now developed another Delphi project group to assist people moving to mORMot.
This contains 2 Delphi programs.

Details of the Delphi programs are at this link :-
http://synopse.info/forum/viewtopic.php?id=3522

The topic is "Generate code for FMX on Windows and Android for mORMot".

I am using my methodology to convert a very large DataSnap project.
Legend
Helpful Answer (5 pts)
Correct Answer (10 pts)

Server Response from: ETNAJIVE02