Datasnap still better in some aspects

I believe Datasnap is still better in some aspects:

1. Cds.Delta property includes automatically what is needed to be sent to server. With ADO .NET a developer has to manually define what is to be sent (through GetChanges method or using custom methods like Select method). GetChanges has some problems though, because it returns a dataset that is different than the original and the whole procedure is much more complicated than the way Datasnap handles things)
2. I read (p. 488 of ADO .NET by David Sceppa) the paragraph titled "Working with AutoIncrement Values and Relational Data". It ends saying " Thanks to functionality of DataRelation objects, cascading the new autoincrement values throughout you hierarchy is the simplest part of the process". However, it is considered a default behavior to "submit the new orders, retrieve the new autoincrement values for the new orders (master) , apply these values to appropriate line items (detail) (automatically through cascades) and then submit the new line items to the database". This means, at least 2 calls to the server should be made. Using my method of applying updates this is performed automatically inside a unique call to app server with automatic wrapping in a transaction (in ADO .NET the user has to explicitly define transactions- this has its pros and cons)
3. The Reconcile method of DataSnap merges propagated changes from server using internal RecNo property and this way it finds where in the delta to "merge" the changes. ADO .NET relies on primary keys to achieve the same thing (using Merge method). This means more manual work from developer perspective: (p. 499) "... removing the new orders (with the "dummy" OrderID Values) from the main Dataset just before we merge in the DataSet returned by the Web service", or alternatively "Change the primary key.... call them PsedoKey". I believe this is much better handled in Datasnap and simplifies developer work a lot (if only it weren't for QC 11761....)