Jim Tierney

This is a continuation of my posts on DataSnap server method parameters and return types.  This post is about  TStream and TDBXStreamValue.    The sample client and server projects that go with this post can be downloaded here: http://cc.embarcadero.com/item/26854

See my earlier posts on “Basic” and “Basic DBXValue” types.   I’ve yet to post about TDBXConnection, TDBXConnectionValue, TDBXReader, TParams, and TDataSet.  However, TDataSet is demonstrated in the sample projects.

The following table summarizes differences between TStream and TDBXStreamValue types:

Supports null values

The TDBXStreamValue type has an IsNull property and a SetNull method.   Use this type instead of TStream a parameter value can be null/nil, in some cases.

Declaration

The var and out keywords can’t be used to specify the parameter direction of a TDBXStreamValue parameter.  The direction is always in/out. A TDBXStreamValue type can’t be used as a function result.

Proxy Generator

The RAD Studio 2007 client proxy generator does not work properly for server methods with TDBXStreamValue parameters. So you will need to hand code the client code or correct the generated proxy. The sample client has hand corrected proxy methods that look like this.

function TTestStreamValueClient.Echo(var I: TStream): TStream;
begin
  if FEchoCommand = nil then
  begin
    FEchoCommand := FDBXConnection.CreateCommand;
    FEchoCommand.CommandType := TDBXCommandTypes.DSServerMethod;
    FEchoCommand.Text := 'TTestStreamValue.Echo';
    FEchoCommand.Prepare;
  end;
  if I = nil then
    FEchoCommand.Parameters[0].Value.SetNull
  else
    FEchoCommand.Parameters[0].Value.SetStream(I, FInstanceOwner);
  FEchoCommand.ExecuteUpdate;
  if FEchoCommand.Parameters[0].Value.IsNull then
    I := nil
  else
    I := FEchoCommand.Parameters[0].Value.GetStream(FInstanceOwner);
  Result := FEchoCommand.Parameters[1].Value.GetStream(FInstanceOwner);
end;

This client method works with a server method declared as follows:

function Echo(I: TDBXStreamValue): TStream;

Calling a server method with a TDBXStreamValue parameter is the same as calling a server method with an TStream parameter, except that you can use SetNull and IsNull methods to work with null values.

For example, compare the following server method declaration and client method implementation to the previous example:

function Echo(I: TStream): TStream; 

function TTestStreamClient.Echo(I: TStream): TStream;
begin
  if FEchoCommand = nil then
  begin
    FEchoCommand := FDBXConnection.CreateCommand;
    FEchoCommand.CommandType := TDBXCommandTypes.DSServerMethod;
    FEchoCommand.Text := 'TTestStream.Echo';
    FEchoCommand.Prepare;
  end;
  FEchoCommand.Parameters[0].Value.SetStream(I, FInstanceOwner);
  FEchoCommand.ExecuteUpdate;
  Result := FEchoCommand.Parameters[1].Value.GetStream(FInstanceOwner);
end;

Accessing Values

The GetStream and SetStream methods have an InstanceOwner parameter.  Passing True indicates that DBX owns the stream and will free it.  Passing False indicates that the caller owns the stream.  To control how the generated proxy classes call SetStream and GetStream, there is an AInstanceOwner parameter on the proxy class constructor:

constructor TTestStreamClient.Create(ADBXConnection: TDBXConnection; AInstanceOwner: Boolean);

The other constructor is equivalent to passing AInstanceOwner as True.

constructor TTestStreamClient.Create(ADBXConnection: TDBXConnection);

Sample Client And Server Applications

The sample server has a few simple server methods for passing values (including null).

  {$METHODINFO ON}
  TTestCollection = class(TComponent)
  strict protected
    procedure LogMessage(const AMessage: string);
  public
    // Server method to get the parameter type names
    procedure GetTypeNames(I: T; ADeclaredName, AActualName: TDBXStringValue);
  end;
  {$METHODINFO OFF}

  TTestStream = class(TTestCollection)
  public
    function Echo(I: TStream): TStream;
    procedure Copy(I: TStream; out J: TStream);
    procedure Swap(var I: TStream; var J: TStream);
  end;

  TTestStreamValue = class(TTestCollection)
  public
    function Echo(I: TDBXStreamValue): TStream;
    procedure Copy(I: TDBXStreamValue; J: TDBXStreamValue);
    procedure Swap(I: TDBXStreamValue; J: TDBXStreamValue);
    function IsNull(I: TDBXStreamValue): Boolean;
    procedure SetNull(I: TDBXStreamValue);
  end;

The sample client tests the server methods by calling them with sample values and verifying the results (e.g; comparing streams). TMemoryStream is used to pass short streams and TFileStream to pass long streams.  Here is a screen shot of the running server and client:

The following table shows the parameter types and return types demonstrated in the sample client and server:

Stream Usage

Check  “Log Stream Usage” to show TStream sizes, type names, creates, destroys, and reads.  The results from 4 different test cases are displayed after “Call Server Methods” is clicked. 

The screen shot below shows the result from a test case with longer streams.  I’ve added highlighting to illustrate these points:

1. When the server reads a longer stream passed from the client, round trips are made to the client.  This makes it possible to send very large streams to the server without consuming lots of memory.
2. When the client reads a longer stream passed from the server, round trips are made to the server.  This makes it possible to return very large streams to the client without consuming lots of memory.
3. The TStream objects that represent longer client and server streams have a Size of –1, meaning the size is unknown.  Rely on the return value of TStream.Read to detect the end of the stream.  Also note that some DBX streams such as TDBXStreamReaderStream do not fully support Seek.

That’s all for now.

Share This | Email this page to a friend

This post provides more information about DataSnap server method parameters and return types. This is my second post on this subject, following DataSnap Server Method Parameters. The previous post was about "Basic" types. This post is about "Basic DBXValue" types.  The sample client and client and server projects that go with this post can be downloaded here: http://cc.embarcadero.com/item/26734

The following table summarizes differences between "Basic" and "Basic DBXValue" types:

�

Supports null values

Support for null values is needed, for example, when a server method needs to pass values that come from a database column that allows NULL.    All DBXValue types have an IsNull property and a SetNull method.

Declaration

The var and out keywords can’t be used to specify the parameter direction of a DBXValue parameter.  The direction is always in/out.   A DBXValue type can’t be used as a function result.

Proxy Generator

The RAD Studio 2007 client proxy generator does not work properly for server methods with DBXValue parameters.  So you will need to hand code.   The sample client has code like this to call a server method:

// Non-generic version of TestSetNull
procedure TCallTestMethods.TestSetNullInt32(AConnection: TDBXConnection; I: Int32);
const
  LMethodName = 'TTestDBXInt32Value.SetNull';
var
  LIsNull: Boolean;
  LDBXCommand: TDBXCommand;
begin
  LDBXCommand := AConnection.CreateCommand;
  try
    try
      LDBXCommand.CommandType := TDBXCommandTypes.DSServerMethod;
      LDBXCommand.Text := LMethodName;
      LDBXCommand.Prepare;
      LDBXCommand.Parameters[0].Value.SetInt32(I);
      LDBXCommand.ExecuteUpdate;
      LIsNull := LDBXCommand.Parameters[0].Value.IsNull;
      LogTestResult(LMethodName, LIsNull);
    except
      on E: Exception do
      LogTestException(LMethodName, E);
    end;
  finally
    LDBXCommand.Free;
  end;
end;

Calling a server method with a TDBXInt32Value parameter is the same as calling a server method with an Int32 parameter, except that you can use SetNull and IsNull methods to work with null values.  

Accessing Values

The following table shows the methods that are used to access a non-null value from the different DBXValue types   A mismatched call, such as GetBcd on TDBXStringValue, will raise an exception. 

�

String Value Types

Of the five DBXValue types that represent strings, you need only use TDBXAnsCharsValue to pass AnsiString values and TDBXWideCharsValue to pass UnicodeString/string values. The following table shows that these two types are always passed to server methods even if the method is declared with one of the other string types.

Sample Client And Server Applications

The sample server has a few simple server methods for passing values (including null), and two informational server methods.  In order to support various DBXValue types, I’ve implemented a generic server method base class:

{$METHODINFO ON}
  TTestBasicDBXValueType = class(TComponent)
  strict protected
    function EqualValues(I: TValue; J: TValue): Boolean; virtual;
    function GetValue(I: T): TValue; virtual; abstract;
    procedure SetValue(I: T; Value: TValue); virtual; abstract;
  public
    // Server methods to pass values (including null)
    function IsEqual(I: T; J: T): Boolean;
    function Echo(I: T): TValue;
    procedure Swap(I: T; J: T);
    function IsNull(I: T): Boolean;
    procedure SetNull(I: T);
    // Server method to get the DBXValue parameter type names
    procedure GetTypeNames(I: T; ADeclaredName, AActualName: TDBXStringValue);
    // Server method to try DBXValue methods like GetInt32 and SetInt32
    function TryGetAndSet(I: T): TDataSet;
  end;
{$METHODINFO OFF}

Then I’ve used TTestBasicDBXValueType to declare and implement server methods classes for a variety of DBXValue types, such as TDBXInt32Value, TTestDBXDateValue , etc.

  TTestDBXInt32Value = class(TTestBasicDBXValueType)
  strict protected
    function GetValue(I: TDBXInt32Value): Int32; override;
    procedure SetValue(I: TDBXInt32Value; Value: Int32); override;
  end;

  TTestDBXDateValue = class(TTestBasicDBXValueType)
  strict protected
    function GetValue(I: TDBXDateValue): TDBXDate; override;
    procedure SetValue(I: TDBXDateValue; Value: TDBXDate); override;
  end;

Consult the sample server to see how I’ve implemented the "plumbing" to make these classes callable by a DataSnap client. As in the “Basic” types sample server, the implementation is unconventional because the TDSServerClass component is not used.

The sample client tests the generated methods by calling them with sample values and verifying the results. Consult the sample for implementation details. Here is screen shot of the running server and client:

The following table shows the parameter types and return types demonstrated in the sample client and server:

That’s all for now.  I plan on covering the collection types in my next post.

Share This | Email this page to a friend