In the previous two CTPs, you simply could not do this (if you tried, you likely received some sort of circular reference serialization error), even though way back in July, pre-beta, you could.
Well, its back. But to take advantage of this, you will need to add the following to your web.config:
<system.web.extensions>
<scripting>
<webServices>
<jsonSerialization>
<converters>
<add name="DataSetConverter" type="Microsoft.Web.Preview.Script.Serialization.Converters.DataSetConverter, Microsoft.Web.Preview"/>
<add name="DataRowConverter" type="Microsoft.Web.Preview.Script.Serialization.Converters.DataRowConverter, Microsoft.Web.Preview"/>
<add name="DataTableConverter" type="Microsoft.Web.Preview.Script.Serialization.Converters.DataTableConverter, Microsoft.Web.Preview"/>
</converters>
</jsonSerialization>
</webServices>
</scripting>
</system.web.extensions>
... and hence forth you shall be able to call webservices or page methods that return System.Data.DataSet/DataTable/DataRow! And there was much rejoicing.
One thing you should know. Way back pre-beta, the client side type you received as a result of calling one of these ado.net loving methods was Sys.Data.DataTable filled with Sys.Data.DataRow and Sys.Data.DataColumn rich client side objects. No longer. Converters now are restricted to returning proper JSON, which cannot and should not include type information. Just data. So the JSON you get is what you would expect for a DataTable. You might see this as negative thing... but in reality it makes much more sense than the previous model. The format is much more compact now. And since all you get back is data, you aren't forced into using the built in client side types. You can more easily roll your own. Also, since you can simply work directly with the data, no client side parsing is needed and no extra types are created.
Plus... If you really need the old type back, you can still get it. Just pass the JSON object into the following method:
var table = Sys.Preview.Data.DataTable.parseFromJson(obj);
And you can once again work with it with the rich client side type. Most likely you should be able to use the json object directly, that would be more performant anyway. If you need to provide the data to one of the built in data controls (Sys.Preview.UI.Data.*), they will automatically convert the object if needed.
If you wish to work with the JSON directly, the following is the format the DataTable will take:
{ columns: [ column1, column2, .... ], rows: [ row1, row2, ...] }
A column in itself will look like:
{ name: "TableName", dataType: ClientSideType(e.g., String),
defaultValue: jsonSerializedValue, readOnly: true|false, isKey: true|false }
Possible data types are: String, Number, Boolean, and Date. isKey is true if the column is or is part of the column's primary key. The rest are pretty obvious.
A row in itself will look like:
{ column1: value1, column2: value2, .... }
Where "column1" is the name of the first column of the data table.
So for example, given a Table's JSON, you can access the 2nd row's BirthDate value like so:
var bday = dataTable.rows[1].BirthDate;
The ability to return ADO.NET objects from WebServices and consume them on the client was sorely missed. Hopefully its return is a happy one!
Happy coding!