Watch, Follow, &
Connect with Us

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


ID: 20273, Stateless, Generic, n-tier CDS.CommandText with Incremental fetc

by Dave Rowntree Email: Anonymous


Demo showing how CDS.CommandText and incremental fetching (CDS.PacketRecords>0) can be used in a generic, stateless n-tier app.
Download Details
FTP  download also available
CDN Login Required to Download. (You will be redirected to the login page if you click on the Download Link)
To download this, you must have registered:
A free membership

For Delphi, Version 7.0  to 7.0 651 downloads
Copyright: No significant restrictions


Size: 9,382 bytes
Updated on Thu, 02 Oct 2003 09:18:14 GMT
Originally uploaded on Thu, 03 Jul 2003 06:53:38 GMT
SHA1 Hash: BA1F6EEA1D91FD6B49FD5885444E26243DDADEC7
MD5 Hash: 87DC6603FBB3C9ADA085E6BA8D28F794

    Explore the files in this upload

Description
Although I personally do not support the idea of having SQL at client app level in an n-tier application, it seems to be a fairly popular requirement to be able to use CDS.CommandText as the sole SQL field in a 3-tier stateless/2-tier application. An additional requirement seems to be to use incremental fetching with this. This would then provide a MIDAS/dbExpress application that has similar characteristics to a BDE application.

This demo app shows how you can use dbExpress/ADO and MIDAS(datasnap) to produce a generic, stateless n-tier, or 2-tier application using only the CDS.CommandText to contain SQL, and have the records brought into the CDS incrementally, using CDS.PacketRecords > 0.

A few of points to bear in mind ...

1. The CDS is a memory based dataset. It holds *all* it's records in memory. If the dataset being returned against the CDS.CommandText has thousands of records, the CDS has the potential to end up with all the records in memory at the same time. The CDS does *not* discard current in memory records when more records are fetched from the DSP. The CDS always contains *all* the records fetched from the DSP since it was opened.

2. A good practice to adopt when designing a MIDAS application is to display zero records when a screen form is opened. Request selection criteria from the user before fetching records, and use the criteria to limit the potential number of records that can be returned from the DSP (normally the selection criteria would be used in a WHERE clause in the SQL).

3. The CDS does *not* need to be connected to the DSP or the DB all the time the CDS is open. Once a call from the CDS to the DSP (GetRecords, ApplyUpdates, etc) have completed their operation, the connection to the DSP and the DB can be closed. This is because the CDS holds all it's records in memory, and the AppServer is stateless. This can substantially reduce resource loading.

   Latest Comments  View All Add New

Move mouse over comment to see the full text

Could not retrieve comments. Please try again later.

Server Response from: ETNACDC03