I explored such a scenario. The best I determine was it can't be done. I
even made such a suggestion to Microsoft during the VS2005 beta cycle, but
it didn't make it to implementation (at least in this product release). The
suggestion seemed well received.
The work-around solution I thought of is to have the initial web service
call return some sort of small index table. Then, with a background thread,
loop through the index table requesting the actual information one item at a
time via web service calls.
For example you might create a table with the fields RequestNo, ItemNo and
ItemData. The initial web service call would perform it search. Say for
example that 5 items are found. The web service generate a new unique
RequestNo, and populate the table with the five items, returning RequestNo
and the number of items. Then your app would loop 5 times using a thread,
each time call requesting item n of RequestNo. And to be nice, you could
then call a third method to flush the table of the RequestNo items.
No, it not efficient in terms of cpu cycles, network traffic, etc. And it
will take actually a larger time frame. But, it does allow the UI to
response to the user and provide the ability to update the information as
received, instead of all at once. As often stated, life is a trade off.
But, if you happen to come up with a better idea, I would love to hear it.
Richard Rosenheim
> I want to create a search usecase on Client which will bring large data from
> webservice to the client.
[quoted text clipped - 9 lines]
> Regards
> Armoghan