From DataSet To SqlDataReader in a CLR Stored Procedure

Hi all,
I'm writing a CLR stored procedure that just execute a query using 2 parameters.

SqlContext.Pipe.Send can send a SqlDataReader, but if I've got a DataSet?
How can I obtain a SqlDataReader from a DataSet?

Dim command As New SqlCommand(.......)
.....
Dim ds As New DataSet()
Dim adapter As New SqlDataAdapter(command)

adapter.Fill(ds, "MyTable")

... 'manipulating the ds.Tables("MyTable")

At this moment I have to send the table...but
ds.Tables("MyTable").CreateDataReader()
just give me a DataTableReader, and i can't send it with SqlContext.Pipe.Send(...

Help me please!
The DataSet.CreateDataReader method can be used to generate a data reader that reads data from a dataset.|||DataSet.CreateDataReader() is the same of dataSet.Table(x).CreateDataReader()...it returns a DataTableReader!
There is also an overload for dataSet.CreateDataReader that get an array of dataTable as parameter!|||Sorry about that. For some reason, I was quite convinced that SqlPipe.Send accepted an IDataReader rather than a SqlDataReader. Looks like you'll need to use SqlPipe.SendResultsRow. See http://msdn2.microsoft.com/en-US/library/microsoft.sqlserver.server.sqlpipe.sendresultsrow(VS.80).aspx for details and sample code.|||Thank you, but i don't think that can be the "best practice", it's not in .net style!!!
I'll search better!|||? It used to accept IDataReader during the betas, all the way up to one of the final CTPs -- then that functionality was removed for some reason :( -- Adam MachanicPro SQL Server 2005, available nowhttp://www..apress.com/book/bookDisplay.html?bID=457-- <Nicole Calinoiu@.discussions.microsoft.com> wrote in message news:7725b945-d2c1-44d0-a698-fa9a344a48d4@.discussions.microsoft.com...Sorry about that. For some reason, I was quite convinced that SqlPipe.Send accepted an IDataReader rather than a SqlDataReader. Looks like you'll need to use SqlPipe.SendResultsRow. See http://msdn2.microsoft.com/en-US/library/microsoft.sqlserver.server.sqlpipe.sendresultsrow(VS.80).aspx for details and sample code.|||

Well, at least I wasn't imagining things. ;)

Based on the current implementation, I'd have to guess that the change may have been made for 2 main reasons: improved performance and enhanced metadata extraction. However, I can't see any reason why an overload that accepts IDataReader couldn't have been left in since the "improved" SqlDataReader implementation would still be used where possible. A wee bit odd...