Making a Client/Server application using Datasnap is pretty straight forward.  The big change over the old DCom design is the connection from client to server, and the server activation method – simply put there is no auto activation.  You’ll have to start the server before running the client.   The old client side TDComConnection is replaced by a TSQLConnection – yes, that’s the same connection component used from the server (TSqlQuery) to the database.

Let’s create the server first. 

1.       Create a new VCL forms application, then add a Server Module (File\New\Other – Delphi Files page) to the application. 

2.       From the Tool Palette \ Datasnap Server – drop a TDSServer, TDSServerClass and TDSTCPServerTransport on the applications main form.

3.       For both the ServerTransport and the ServerClass, set the Server property to the TDSSserver component.

4.       On the ServerClass, add an event in for the OnGetClass method.   In the event itself you need to assign the PersistentClass variable to the ServerModule you created in step one.  You’ll need to add it to the main forms uses clause first.  ie.  PersistentClass := TDSServerModule2;

5.       On your Server Module, drop a TSqlConnection, TSqlQuery and TDatasetProvider component.  Set the SqlConnection.ConnectionName to your database,  SqlQuery.SqlConnection to the SqlConnection, and DatasetProvider.Dataset to the SqlQuery.  Also add the SqlQuery.Sql to query a table in your database.

6.       Build the server

Now that we’ve got the server created, lets build the client.

1.       Create a new VCL forms application.

2.       Drop a TSqlConnection on to the main client form, set the Driver property to DATASNAP.  Assign params for the following Key|Value combinations:  DriverName | Datasnap,  Hostname | LocalHost,  Port | 211.  Note the Port 211 is the default, however you can reassign the client & server ports to a different value.  Each Datasnap server must use a different port, running a 2^nd datasnap server that is using the same port of an existing running one will cause a 'Socket already in use' error message.

3.       Add a TDSProviderConnection to the main form, set the SqlConnection property to the TSqlConnection on the client form, and set the ServerClassName to the object name of the TDSServerModule that you created in step 1 of the server (ie.  TDSServerModule1).

4.       Add a TClientDataset, TDatasource, and TDBGrid.   Set the ClientDataset.RemoveServer to the DSProviderConnection, the Datasource.Dataset to the ClientDataset, and the DBGrid.Datasource to the Datasource.

5.       At this point, if you run the server then edit the ClientDataset.ProviderName property, it should show your DatasetProvider in the drop down list if everything is hooked up properly.  Setting the ClientDataset.Active = True should display the results of your query in the DBGrid.

That’s all there is to the basics of how to connect a client application to the server using the Datasnap architecture. 

Some good reading on the basics of Datasnap:

• DataSnap 2009 Overview
• DataSnap 2009 Memory Management
• DataSnap 2009 Threading Model

Been doing some R&D with the new Delphi 2009 and checking out the new Datasnap architecture, I came across this gem of a problem.  The TDSServerClass CreateInstance calls the TDSServerModule create method, but the TDSServerClass DestroyInstance doesn't call the ServerModule Destroy.  Thus any code put in the destroy isn't called (like closing the database connection), and the ServerModule is a memory leak.  I bumped in to this problem by putting something as trivial as an OutputDebugString into the DestroyInstance event.

Per a comment by Leonel (CodeGear) in the NG's, if there is any code in the TDSServerClass.DestroyInstance, then the intent is that the developer has to free the ServerModule themself.   This violates one of the most basic rules of Delphi, as layed out by Danny Thorpe in his book "Delphi Component Design", that having or not having code in an event by itself alters the component.  The real kicker of this is that the help on the TDSServerClass methods is pretty sparse, and no where does it detail this component changing 'feature'.

The work around to this is either a) don't put any code in the TDSServerClass.DestroyInstances, or if you must then use DSDestroyEventObject.ServerClassInstance to reference the ServerModule and destroy it.