Thursday, October 1, 2015

Bad coding only?

Long time not seen, been around doing things i may publish at a later stage.
Lately i am maintaining an existing Delphi software and strangling with some piece of code.
To who ever writes such code: Please do not do that, my eyes are in pain and my brain f@...d.

  ChargeIdx := TSupportedContract(TSupportedCarrier(TariffList.Objects[Carrieridx]).
  if (ChargeIdx = -1) then
      FContracts.Objects[ContractIdx]).FChargeList.AddObject(ChargeCode, TSupportedCharge.Create);

    ChargeIdx := TSupportedContract(TSupportedCarrier(TariffList.Objects[Carrieridx]).FContracts.Objects[ContractIdx]).FChargeList.IndexOf(ChargeCode);

  ServiceIdx := TSupportedCharge(TSupportedContract(TSupportedCarrier(TariffList.Objects[Carrieridx]).
  if (ServiceIdx = -1) then
      FContracts.Objects[ContractIdx]).FChargeList.Objects[ChargeIdx]).FServices.AddObject(ServiceCode, TSupportedService.Create);
    ServiceIdx := TSupportedCharge(TSupportedContract(TSupportedCarrier(TariffList.Objects[Carrieridx]).

  PackageIdx := TSupportedService(TSupportedCharge(TSupportedContract(TSupportedCarrier(TariffList.Objects[Carrieridx]).
  if (PackageIdx = -1) then
      FContracts.Objects[ContractIdx]).FChargeList.Objects[ChargeIdx]).FServices.Objects[ServiceIdx]).FPackages.AddObject(PackageCode, TSupportedPackage.Create);
    PackageIdx := TSupportedService(TSupportedCharge(TSupportedContract(TSupportedCarrier(TariffList.Objects[Carrieridx]).

  ZoneIdx := TSupportedPackage(TSupportedService(TSupportedCharge(TSupportedContract(TSupportedCarrier(TariffList.Objects[Carrieridx]).
  if ZoneIdx = -1 then
    ServiceZone := TSupportedServiceZone.Create;
    ServiceZone.ServiceZone := ReadServiceZone(qry);

        AddObject(IntToStr(ServiceZone.ServiceZone.ChargeLinkID), TObject(ServiceZone));

    ZoneIdx := TSupportedPackage(TSupportedService(TSupportedCharge(TSupportedContract(TSupportedCarrier(TariffList.Objects[Carrieridx]).

  Charge := TCharge.Create(FSessionID);
  Charge.FDiscount := qry.FieldByName('DISCOUNT').AsFloat;
  Charge.Charge := ReadCharge(qry);

      Objects[ZoneIdx]).FCharges.AddObject(IntToStr(Charge.Charge.ID), TObject(Charge));

Monday, July 9, 2012

From TParams to TDatasetRecord and beyond

It has been a while since my last blog post. due to many job problems and the economical crisis here at Hellas (Greece). Anyway, for those who have followed my previous posts on "A journey to TParams", i will try to get TDatasetRecord (the class derived from TParams) a bit further, by explaining some aspects of creating derived classes with dataset field mappings.

TDatasetRecord is the class created to to represent a single dataset record. In fact it does not just represents a record, it mainly holds and provides access to record field values even disconnected from the actual dataset. As a descentant of TParams it uses TParam object to fullfil these requirements. Field values can be accessed by using normal TParam(s) methods and properties or TDatasetRecord.Field method, ie:


This is useful, if you agree, but what is so big deal with? As is for now, nothing big, nothing fancy, nothing ... except, if we could have something that really goes into object relational mapping.

First of all, we should be able to access the field as a property of the class and do something like this:


So lets get in detail with Delphi and do it. 
Of course we have to define a class derived from TDatasetRecord specifically for our contact dataset entity as sample and then make some cooking deriving just a base class method and defining properties.

The key method to derive is FieldNames. FieldNames class method is intended to return a name from a predefined list of field names for a specific class derived from TDatasetRecord. Base class's implementation just returns an empty string, but derived ones may change it by overriding this method.

FieldNames method can be overriden to return a string -the fieldname- defined in a const array of strings based on it's index. This method is used by internal functionality of TDatasetrecord to build it's fields -TParam- structure  by forcing which fields will be taken in account. This ensures that the record class will always have the same fields structure and at specified positions in the list of fields (actually TParams collection). For more detail you may refer to the implementation of TDatasetRecord.CreateFields method.

Next method of TDatasetRecord to take into consideration is GetParam, which provides access to internal TParam objects based on FieldNames method. Here is it's implementation:

function TDatasetRecord.GetParam(Index: integer): TParam;
  Result := ParamByName(FieldNames(Index));

Now that we have a way to define the internal fields structure and a field object access method by index we can go on and define properties with index specifiers. Index specifiers allow several properties to share the same access method while representing different values and thus GetParam method of TDatasetRecord can do this job for our contact class properties and map fieldnames to TParam objects.

Now let's built it.
Suppose we have to deal with a dataset of contacts with the following fields available:

  • ContactID
  • FirstName
  • LastName
  • DateOfBirth
  • Father
  • Mother
  • Phones
  • Address
  • SocialSecurity
  • CompanyName
  • BankAccount
So, here is the interface section:

  TContactRecord = class(TDatasetRecord)
    function GetFullName: string;
    class function FieldNames(Index: integer): string; override;
    procedure UpdateDataset;
    procedure AppendDataset;
    property ContactID                : TParam index  0 read GetParam; //ContactID
    property FirstName                : TParam index  1 read GetParam; //FirstName
    property LastName                 : TParam index  2 read GetParam; //LastName
    property CompanyName              : TParam index  3 read GetParam; //CompanyName
    property Phones                   : TParam index  4 read GetParam; //Phones
    property Address                  : TParam index  5 read GetParam; //Address
    property FullName: string read GetFullName;

And the implementation section:

class function TContactRecord.FieldNames(Index: integer): string;
const Names: array[0..5] of string = (
             'ContactID',                  //0 ContactID
             'FirstName',                  //1 ContactName
             'LastName',                   //2 LastName
             'CompanyName',                //3 CompanyName
             'Phones'.                     //4 CompanyName
             'Address'                     //5 CompanyName
 if (Index < Low(Names)) or (Index > High(Names)) then Result := ''
 else Result := Names[Index];
function TContactRecord.GetFullName: string;
  Result := Lastname + ', ' + FirstName;


  • Field position is irrelevant as TDatasetRecord maps it's fields by name, not by position. 
  • We may not want to include all data fields in our class.
  • I also have added a new property that returns the fullname of the contact by concatenating FirstName and LasName. Just a hint of extending the class...

Monday, April 23, 2012

How to: on the fly create runtime data aware controls

There are many situations where you have a dataset with unknown fields structure or you just want to popup a small form and present to user some specific fields from the dataset , ie the fields need to be edited after an unsuccessful validation.

So, here is a simple function i have been using for long time ago to create data aware controls on panels, dialogs, scrollboxes:

uses StdCtrls, DB, DbCtrls, TypInfo;

  Label_W: integer = 200; {@ Width of the label controls}
  Control_W: integer = 500; {@ Max width of edit controls}
  Ctrl_Ident: integer = 2; {@ Distance between controls (horz & vert)}

function CreateDatasetEditor(
         COwner: TComponent; {@ The owner of control, it will be responsible for destruction}
         WParent: TWinControl; {@ The parent window where controls will live in}
         DSource: TDataSource; {@ TDataSource to be associated with controls}
         const Names, {@ Array of field names to use
               (optional, empty array will use all fields from TDataSource.Dataset}
               Labels: array of string; {@ Array of labels to use
               (optional, empty cells will use field.DisplayLabel }
         X: integer; Y: integer {X,Y coordinates in WParent to start positioning controls}
         ): TRect; {@ Result TRect used to place controls}

var i, j, iHigh: integer;
    c, ic : TControl;
    s: string;
    fld: TField;
    iL,iT: integer;
    Fields: TFields;
    Canvas: TControlCanvas;

 {@ Create a label control}
 procedure CreateDBLabel(ForField: TField; LabelText: string);
    with TLabel.Create(COwner) do begin
     Parent := WParent;
     AutoSize := False;
     Left := iL + Ctrl_Ident; Inc(iT,Ctrl_Ident); Top:=iT;
     Width := Label_W;
     WordWrap := False;
     if LabelText<>'' then
        Caption := LabelText
        Caption := ForField.DisplayLabel;
     Alignment := taRightJustify;
     AutoSize := True;
     Transparent := True;

 {@ Create editing data aware control}
 function CreateEditField(ForFld: TField; sLabel: string): TControl;
 var w, h: integer;
  {@ Create edit control's associated label}
  CreateDBLabel(ForFld, sLabel);

  {@ Create actual data aware control based on filed info}
  if (ForFld.DataType in [ftBoolean]) then begin
      Result := TDBCheckBox.Create(nil);
  if (ForFld.DataType in [ftMemo, ftFmtMemo]) then begin
      Result := TDBMemo.Create(nil);
      Result.Width := Control_W;
  if (ForFld.FieldKind = fkLookup) then begin
      Result := TDBLookupComboBox.Create(nil);
      Result := TDBEdit.Create(nil);

  {@ Insert created control to COwner component hierarchy (for destruction puproses)}
  {@ Set control parent, width and other properties}
  Canvas.Control := Result;
  Result.Parent := WParent;
  Result.Enabled := not ForFld.ReadOnly;
  case ForFld.DataType of
    ftWord, ftSmallInt, ftInteger, ftAutoInc, ftLargeint: w := Canvas.TextWidth('###,###,###,###,###')+25;
    ftCurrency, ftFloat: w := Canvas.TextWidth('###,###,###,###,##0.00')+25;
    w := ForFld.DisplayWidth * Canvas.TextWidth('W')+50;
    h := Canvas.TextWidth('Wq')+3;
  if not (ForFld.DataType in [ftMemo, ftFmtMemo]) then
     if w > Control_W then Result.Width := Control_W else Result.Width := w;
  {@ Connect control to DataSource & Field}
  {@ Final adjustment of control width}
  if Result.Width > Control_W then Result.Width := Control_W;

 {@ Position a control in sequence}
 procedure PositControl(c: TControl);
  c.Left := iL + Ctrl_Ident*2 +Label_W; c.Top:=iT; Inc(iT,c.Height);
  Result.Bottom := iT;
  if Result.Right < c.BoundsRect.Right then
    Result.Right := c.BoundsRect.Right;

 if not Assigned(DSource.DataSet) then Exit;
 Fields := DSource.DataSet.Fields;
 Result.Left := X;
 Result.Top := Y;
 Canvas := TControlCanvas.Create;
 iHigh := High(Labels);
 if Length(Names) > 0 then
    begin // Create controls from Names array
    for i:=0 to j do begin
      fld := Fields.FindField(Names[i]);
      if Assigned(Fld) then begin
        if (i<=iHigh) then s := Labels[i];
        c := CreateEditField(Fld,s);
        if Assigned(c) then
    begin //Create controls from dataset.fields
    for i:=0 to j do
      if (i<=iHigh) then s := Labels[i];
      c := CreateEditField(Fields[i],s);
      if Assigned(c) then
 finally Canvas.Free;

Have fun developing, because development is fun!

Tuesday, April 10, 2012

How to: Clone TField and TDataset fields structure

This is just a quick tip on how to copy field structure between TDatasets. The interesting part is the "CloneField" function that duplicates the exact class of a TField from one dataset to another.

First the loop that iterates through a source dataset fields collection and clones each item (TField) to  another dataset, the destination. It takes as parameters a source TDataset from where fields structure will be read, a destination TDataset where fields will be created and a boolean that instructs the procedure to add the fields to the existing structure or exactly clone the source structure.

procedure CopyFields(SourceDataset, DestDataset: TDataset; doAdd: Boolean);
var i,p: integer;
    Fld: TField;
    dFld: string;
  if not doAdd then DestDataset.Fields.Clear;
  for i:=0 to SourceDataset.Fields.Count-1 do
    if Assigned(DestDataset.Fields.FindField(SourceDataset.Fields[i].FieldName)) then
    Fld := CloneField(SourceDataset.Fields[i], DestDataset.Fields.Dataset);
    Fld.DataSet := DestDataset.Fields.Dataset;

Notice the lines:

Fld := CloneField(SourceDataset.Fields[i], DestDataset.Fields.Dataset);
Fld.DataSet := DestDataset.Fields.Dataset;

The first is the call to "CloneFields" function that creates and returns a new TField object and the second that actually binds the field to the destination dataset. This is required in order to have a functional field in the dataset. Do not rely to the owner of the field that could be any TComponent, ie the form, which is the owner of persistent fields we create with the Delphi form designer.

Now, the function that creates an exact TField descendant class based on another one:

function CloneField(Source: TField; AOwner: TComponent): TField;

  procedure SetProp(Name: string);
  var V: variant;
      PropInfo: PPropInfo;
   PropInfo := TypInfo.GetPropInfo(Source, Name);
   if PropInfo <> nil then 
     try V := TypInfo.GetPropValue(Source,Name);
      if not VarIsNull(V) then 
      ; //just kill exception

  Result := TFieldClass(Source.ClassType).Create(AOwner);

  Result.Alignment              := Source.Alignment;
  Result.AutoGenerateValue      := Source.AutoGenerateValue;
  Result.CustomConstraint       := Source.CustomConstraint;
  Result.ConstraintErrorMessage := Source.ConstraintErrorMessage;
  Result.DefaultExpression      := Source.DefaultExpression;
  Result.DisplayLabel           := Source.DisplayLabel;
  Result.DisplayWidth           := Source.DisplayWidth;
  Result.FieldKind              := Source.FieldKind;
  Result.FieldName              := Source.FieldName;
  Result.ImportedConstraint     := Source.ImportedConstraint;
  Result.LookupDataSet          := Source.LookupDataSet;
  Result.LookupKeyFields        := Source.LookupKeyFields;
  Result.LookupResultField      := Source.LookupResultField;
  Result.KeyFields              := Source.KeyFields;
  Result.LookupCache            := Source.LookupCache;
  Result.ProviderFlags          := Source.ProviderFlags;
  Result.ReadOnly               := Source.ReadOnly;
  Result.Required               := Source.Required;
  Result.Visible                := Source.Visible;


The first line of code is the one that creates a new TField descendant from the actual source field class.
Then is the block of base TField common properties assignement, followed by a block of property assignements using runtime  library information (TypInfo) for properties that MAY exist in the actual class. If some of the properties do not exist in the actual class, then they are simply ignored.

Some things to remember:
1.The "doAdd" parameter in "CopyFields" when True results to fields added to the destination fields structure, whilst False forces first to clear the destination fields collection resulting to an exactly same field structure to the destination dataset as the source one.
2.DestDataset has to be inactive in order to call either of the above functions.
3.In "CloneField", if used stand-alone,  "AOwner" represents the TComponent parameter that will be responsible for freeing the field. Usually you will pass the TDataset that the resulting field belongs to, so when the dataset closes it will also be freed.

Have fun developing, cause development is fun!

Saturday, March 31, 2012

TParams, a bit deeper with TDatasetRecord

Well, after two very basic and introductory posts about TParams (post 1, post 2), I think it is time to explain in more detail why I am so excited about. It is not about high-end programming, nor about beauty of coding, nor even about state of the art software development. It is just simplicity!

Now that some basic functionality of TParams has been showed off I can go further and deep into using it in data operations.

As I mentioned in other posts and especially in the first, a typical usage of TParams is to hold the values of the fields from a single database record. I also introduced some utility functions that help communication between TParams and the fields of a dataset.

In fact I rarely use such a procedural approach; I have long time ago crucified COBOL ;) .
Delphi is object oriented and as such we have the option to create classes and encapsulate such functionality. Delphi XE2 introduced a nice new feature; class helpers, for extending existing class functionality, but here we do not want to extend the actual TParams class. We will create a new branch with usages beyond what Borland originally designed for this piece of code. Using plain old inheritance we will create a new class, derived from TParams, which will support the two way communication with datasets.

The class should –in general- be able to:
  • Clone and hold data from a given dataset.
  • Process the data without touching the actual dataset ones.
  • Work in an offline scene with data.
  • Upload data to datasets.

And most importantly, these accomplishments should be almost encapsulated in class and sets of classes that can be extended and adapt specific processing needs by using OOP techniques. Such techniques can be to communicate data between classes, modules, programs and network, create hierarchical lists and associations and even relationships.

In order to accomplish these tasks the class should be able to:
  • Store and access data much the same -pretty- way a dataset access its fields.
  • The class should be able to build its fields based on a given TDataset existing fields structure.
  • The class should be able to transfer field values from a given dataset and back to the same or another dataset corresponding fields.

Some extended functionality could be to add a new record or update an existing one to a dataset, or even delete a record.

Well instead of writing a long blog post, I think it is better to deep into my code. So I have created a project at where you can find the class and a demo project.

Here is the interface part of the class with descriptive remarks for each member:
{@ TDatasetRecord
   Class to represent a dataset record in a TParams collection with each
   TParam serving as a named field/value corresponding to a dataset field}
TDatasetRecord = Class( TParams )
  FDataset: TDataset; {@ Dataset associated with the recordclass}
  FUpdateDataset: TDataset; {@ Dataset to update from recordclass data}
  FRecordAvailable, {@ Record class has it's fields (TParams) created and bound them}
  FRecordExists,    {@ Record has beed loaded from a dataset }
  FIncludeAllFields: Boolean; {@ Create all fields from the dataset}
  function GetParam(Index: integer): TParam;
  function GetDataSet: TDataSet;
  procedure SetDataSet(Value: TDataSet);
  function GetUpdateDataSet: TDataSet;
  procedure SetUpdateDataSet(Value: TDataSet);
  function GetFieldValue(const FieldName: string): Variant;
  procedure SetFieldValue(const FieldName: string; const Value: Variant);
  {@ Initializes recordclass and refreshes current recordfield values from Dataset}
  procedure Initialize(RDataset: TDataset; UDataset: TDataset=nil);
  {@ Create recordclass fields }
  procedure CreateFields; virtual;
  {@ Used by derived classes to set a predefined list of allowed
     recordclass fieldnames}
  class function FieldNames(Index: integer): string; virtual;
  {@ Construct recordclass connecting to a Dataset, and optional an update dataset}
  constructor Create(RDataset: TDataset; UDataset: TDataset=nil); reintroduce; virtual;
  destructor Destroy; override;
  function AddField(FldType: TFieldType; const FieldName: string): TParam;
  {@ Add recordfields from an object (TDataset, TFIelds, TFieldList, TFieldDefs) }
  function AddFields(Source: TObject): integer;
  {@ Assign, TParams collection override }
  procedure Assign(Source: TPersistent); override;
  {@ Get a new recordclass object cloning self properties, fields & data}
  function CloneRecord: TDatasetRecord;
  {@ Set/Unset recordfields Bound property, Bound=False clears all TParam values }
  procedure BoundRecord(DoBound: Boolean);
  {@ Get a list of recordfields defined in FieldNames string }
  procedure GetFieldList(List: TList; const FieldNames: string);
  {@ Get a FieldNames string stuffed with all recordfield names }
  function GetFieldNames: string;
  {@ Test Target Fields against recordfields for equal values }
  function EqualsTo(Target: TDatasetRecord; UseFields: string = ''): Boolean;
  {@ Set UpdateDataset field values from recordfields }
  function SetDatasetFields: integer; overload;
  {@ Set Target Dataset field values from recordfields }
  function SetDatasetFields(Target: TDataset): integer; overload;
  {@ Set recordfield values from corresponding From Dataset fields }
  procedure SetRecordFields(From: TDataSet; UnBound: Boolean); overload;
  {@ Set recordfield values from corresponding From recordclass fields }
  procedure SetRecordFields(From: TDatasetRecord; UnBound: Boolean); overload;
  {@ Retrieve recordfield values from current dataset record}
  procedure RefreshRecord(DoOpen: Boolean=True);
  {@ recordField access method by name }
  function Field(Value: string): TParam;
  {@ RecordClass has been filled with recordfield values }
  function IsAvailable: Boolean;
  {@ Associated dataset record existed when recordclass filled with values }
  function IsExisting: Boolean;
  property Dataset: TDataset read GetDataset;
  property UpdateDataset: TDataset read GetUpdateDataset write SetUpdateDataset;
  property IncludeAllFields: Boolean read FIncludeAllFields write FIncludeAllFields default True;
  property FieldValues[const FieldName: string]: Variant read GetFieldValue write SetFieldValue; default;
You can download source code files and a simple Datasnap XE2 demo here:

and at sourceforge project:

Friday, February 24, 2012

The Era of Dark Backgrounds

Today i had the idea to migrate old RMCOBOL flat files to SQL server in order to test my new datasnap app with real data. All i had to do was write some programs that read the files and write the data to sequential csv format. COBOL programs of course...

Apart of the fact that i had forgotten many syntax rules and statements of COBOL and needed to find the reference manuals, i also had a 20 years flash back. I just felt the need to write some words about at these days, the "era of dark backgrounds" development was a lot different than today. Building an application was almost a totally hand written task. No mouse, no click, no visual design, no online help, no Internet.

Few of the differencies were captured at my monitor during this flash back. Delphi XE2 IDE stands behind the COBOL "IDE".

The IDE, usually a plain text editor. Some of them had a lot of advanced features like mark blocks of text and move, copy, overwrite like simple copy&paste and if you were lucky a limited and occasional Undo. Syntax highlighting, code completion, syntax & statement help, refactoring, history and compare, code insight and other features of modern IDEs, like Delphi XE2 or even early versions of Delphi, was pure science fiction.

Project Manager, off course we had such a feature, who could not write at DOS command line the most simple command of all "c:\>dir /w *.cbl" ?
Who could not write a simple batch file to compile all or some of the project sources? ... dont ask me what is a batch file!

Compiling was also just a simple command like "c:\>rmc85 myprog". But when it comes to error messages, lets say you not only needed to have the -RTFM- books  in hand ...

I cannot show you any screen shots of debugging a program. When it comes to debugging we simply had ... almost nothing. Run the program and ... pray not to have forgotten a dot (.) inside and "IF" ! If you could not follow the program logic from the source files, there was nothing else to help you inspect the program flow.

"Dark backgrounds development was so hard and difficult?" you may wonder. I do not  have an answer, the only thing i know is that development was always about creation and of course fun!

Thursday, February 23, 2012

From COBOL to DataSnap XE2

Many years ago I had built an automation server for my accounting platform using Delphi 6. It was based on TRemoteDatamodule and the Midas components TDatasetProvider & TClientDataset. It was a discovery for me especially speaking for TClientDataset and its unlimited features not only as a Midas client but as a standalone dataset fulfilled with capabilities that a blog post would not be enough to describe.

A couple of weeks ago, after I finished installing and familiarizing my self with the brand new Delphi XE2, I started studying its DataSnap technology. I have to say that I was somehow impressed by the bunch of features I had seen in demos, videos and webinars. Off course Midas components are still at the first line of building database client/server apps with DataSnap, but also a lot of other technologies have been added or heavily enhanced.

Some of them that I noticed are:
  • Datasnap server with TCP/IP and HTTP(S) protocols
  • Server classes with exposed methods to remote clients
  • JSON object marshalling & un-marshalling
  • Enhanced DBExpress framework (though I have never used it),
  • DataSnap Connectors for Mobile Devices !
  • DataSnap Callbacks
  • Authorization & Authentication
  • And many others that complete a long list to mention.
I was so confused with all these that I decided to give it a real world try by converting a old (from 1989) COBOL application to DataSnap. 
Did I said “Convert” ? Fully rebuild is the right choice of words. 

As database layer I was planning to stick with my well known SQLServer and ADODB in order to focus on Datasnap only. After database schema decided and built into SQL Server, I started the DataSnap server wizard of Delphi XE2. Choose “VCL Forms Application”, enabled all features except HTTPS and selected TDSServerModule as server methods class. 
  • VCL Form selected in order to have a live server interface to do things like message logging, start/stop server, monitor its activity etc.
  • All features selected in order to be able to test most DataSnap capabilities and be ready for mobile clients.
  • TDSServerModule as server methods class provides a TDatamodule surface for VCL non-visual components and IAppServer interface which is essential for Dataset providers and clientdatasets communication (Midas).
The project the wizard  created was a lot different from what I was used using Automation with TypeLib and TRemoteDatamodule, but a few hours later I (think) had a clear understanding of the framework. The major aspects I acknowledge in simple terms are:
  • VCLForm: the main form for monitoring server activity
  • Container: a TDatamodule that is the main server module containing among other components a TDSServer, the class that manages transports from and to remote clients and server classes, a TDSServerClass which in turn used to specify a server-side class.
  • ServerMethods: a TDSServerModule supporting IAppServer interface and contains the published methods that can be called from a remote client using dynamic method invocation.
How these works is pretty simple at its basics. 

Requests are served through the Container’s TDSServer component which coordinates traffic with the help of the other container components. 

As for the TDSServerClass it is the component responsible for creating its associated ServerMethods class. 

ServerMethods class exposes to remote clients its public methods and for the TDSServerModule especially the IAppServer interface for provider/clientdataset communication (Midas).

You can create as many classes as you want, either TComponent, TDataModule, TDSDataModule and expose their published methods, and IAppServer Interface in case of TDSDataModule, by just adding a TDSServerClass component in your server Container and respond to its “OnGetClass” event like this:

procedure TMyServerContainer.DSMyServerMethodsGetClass(DSServerClass
  : TDSServerClass; var PersistentClass: TPersistentClass);
  PersistentClass := TMyClass; //Class of your TComponent, TDatamodule, TDSDataModule

At client side now I had to create a VCL forms application and connect to the server to retrieve and present data for editing to the user. Three components do the base job:
  • TSQLConnection: is the connection component that encapsulates a dbExpress connection to a database server. It can connect to various database server but in the case mentioned it connects to my DataSnap server using tcp/ip protocol.
  • TDSProviderConnection: a component that provides connectivity to a DataSnap server methods class, the above mentioned ServerMethods (TDSServerModule), using dbExpress.
  • TClientDataset: connected to the TDSProviderConnection via RemoteServer property and to the actual provider of the data in ServerMethods via ProviderName property.
I won’t describe further the details of setting the properties of those components as there are a lot of video presentations and articles at the official Embarcadero site & blogs. Also having a close look at the DataSnapXE projects in your XE2 samples folder is a must and I found them to be very much helpful.

Back to now, the business logic of my project is already implemented at the server and test clients have succeeded testing and coordinating them.

TClientDataset works as expected and a few extra communication needed between client and server implemented based on streaming TParams (TParamsStorage) via OwnerData. I use a lot this technique to pass info from one module to another and especially for passing user input from UI forms to datamodule methods that need to build runtime queries and return result sets for browsing, reporting etc. See my article series “A Journey to TParams” for more info.

Client Reporting requests are served from the server as entities of ClientDataset XmlPackets and processed at the client and the only things left are UI enhancements. Hope it soon will be completed so i can dig in more interesting aspects like Mobile connectors.