Hi,



I am using VS2005 and .NET 2.0



I have a WebMethod that accept a typed data table. I realized that whatever
rows that client sends to the SOAP server through the datatable, the
webmethod received an empty datatable!!



After spending several hours, I found that the only kind of data table that
I can pass it to a webmethod is detached datatable. If data table is
attached and part of a dataset, then the webmethod receives an empty
datatable!



Is that true? Or I am missing something?



Thank you,

Alan

RE: ADO.NET 2.0, WebMethods and datatable strange behavior by v-kevy

v-kevy
Mon Jan 30 21:14:51 CST 2006

Hi Alan,

During the research on this issue, I found if a web method returns a
datatable, the proxy created when you create a web reference to that web
service in a client application is not representing properly.

http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackid=6
13c616c-a3f6-473c-b3cd-2c910af42cfa

From the above bug, we can see it is by design, because DataTable is not
special cased in the WSDL- or proxy-generation code, meaning it is treated
the same as any other user-defined type. In general, the proxy-generator
does not try to associate incoming WSDL with an existing user-defined or

Re: ADO.NET 2.0, WebMethods and datatable strange behavior by A

A
Tue Jan 31 09:11:17 CST 2006

Hi Kevin,

The bug that you referred me to is a beta 2 bug. I think the proxy generator
behaves fine with respect to BUG# FDBK25605.



Moreover, BUG# FDBK25605 it is with regards to type problem in WebMethods
that return datatable. My case is totally different. In my case there is a
problem with webmethods that receive a datatable as its parameter and the
proxy doesn't stream data to the web method.



Were you able to reproduce the bug? Is it going to be an official bug in
proxy generator?

Or this is a by design behavior?



Since I am going to suggest some radical changes in our application
architecture to our client, I appreciate if you could provide me some
official knowledge base ID or bug ID.



Thank you for help,

Alan







"Kevin Yu [MSFT]" <v-kevy@online.microsoft.com> wrote in message
news:VnoXGShJGHA.1240@TK2MSFTNGXA02.phx.gbl...
> Hi Alan,
>
> During the research on this issue, I found if a web method returns a
> datatable, the proxy created when you create a web reference to that web
> service in a client application is not representing properly.
>
> http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackid=6
> 13c616c-a3f6-473c-b3cd-2c910af42cfa
>
> From the above bug, we can see it is by design, because DataTable is not
> special cased in the WSDL- or proxy-generation code, meaning it is treated
> the same as any other user-defined type. In general, the proxy-generator
> does not try to associate incoming WSDL with an existing user-defined or
> net framework type.
>
> This can also suggest why there is no data in the DataTable when passed to
> server.
>
> Instead of using DataTable, I suggest using Dataset, which is
> special-cased
> in the WSDL- and proxy-generation code, and will show up in your proxy as
> Dataset.
>
> HTH.
>
> Kevin Yu
> =======
> "This posting is provided "AS IS" with no warranties, and confers no
> rights."
>



Re: ADO.NET 2.0, WebMethods and datatable strange behavior by v-kevy

v-kevy
Wed Feb 01 00:49:43 CST 2006

Hi Alan,

I tried to reproduce this on my machine, but whenever I use a DataTable as
parameter of a webmethod, BUG# FDBK25605 is preventing me from getting a
proxy with correct webmethod generated. It is always giving another
webmethod with different type of argument generated as stated in the bug
description. So I even cannot repro the problem you met.

Also, from the document, it is NOT recommended to use a DataTable as the
argument of a webmethod. As I stated, DataTable is not special cased in the
WSDL- or proxy-generation code. If you're changing your app's architecture,
I suggest you try to put the DataTable into a DataSet and it will be
working fine.

Kevin Yu
=======
"This posting is provided "AS IS" with no warranties, and confers no
rights."