Smart Client Questions

hello there. i have been asked to develop a smart client application, and
the first task is to develop a reporting module. i've got a few questions
please.

1. i am concerned that outputting potentially large datasets of reporting
data via a web service might mean a big performance hit. am i right to be
concerned? if so, what steps can i consider to solve this problem?

2. if performance IS an issue then i have already considered caching the
data locally to prevent unnecessarily hitting the web service. however, this
is reporting data, so by nature it is changing frequently. the easiest
solution is to hit the web service every time. an alternative would be to
update a timestamp field for each report, updated via triggers, giving a
quick indication of whether the cached data was stale or not. however, as
the database contains hundreds of reports, many of which contain multiple
joins, this seems to be a nightmarish prospect to set up, and very error
prone. is this a common issue with smart client development? what steps
should i consider taking here?

thanks for your advice. it all makes sense to me.

"Buying the user small puzzles or sudoku books to keep them occupied while
they wait for their reports."

lol

By this, do I take you to mean that smart clients look good on paper, but in
practice run like a one legged horse?



"Ciaran O''''Donnell" <CiaranODonnell@discussions.microsoft.com> wrote in
message news:E2268F3C-DD47-4054-8B9A-E4E333FA301D@microsoft.com...
>I would:
> 1) Consider using something smaller than a dataset if possible, it
> transmits
> itself as XML and that can make it larger, Custom object could be smaller
> and
> with WCF could be binary serialised which would be faster to do and faster
> to
> send.
>
> 2) Look at filtering as much as possible on the server. Providing summary
> reports so people dont get detail if they dont need it, date ranging
> reports,
> that kind of thing.
>
> 3) Produce the reports on SQL Server with reporting services etc to make
> use
> of better machines and data locality.
>
> 4) Produce the reports asynch by queuing the requests and emailing people
> when they are ready, possible attaching them.
>
> 5) Look at a rendering option which allow data appening so you could get
> the
> first page of the report, then while they are looking at that, get the
> rest.
> This depends on the type of report, rendering engine etc.
>
> 6) Buying the user small puzzles or sudoku books to keep them occupied
> while
> they wait for their reports.
>
> HTH
> --
> Ciaran O''''Donnell
> http://wannabedeveloper.spaces.live.com
>
>
> "Fidget Brain" wrote:
>
>> hello there. i have been asked to develop a smart client application, and
>> the first task is to develop a reporting module. i've got a few questions
>> please.
>>
>> 1. i am concerned that outputting potentially large datasets of reporting
>> data via a web service might mean a big performance hit. am i right to be
>> concerned? if so, what steps can i consider to solve this problem?
>>
>> 2. if performance IS an issue then i have already considered caching the
>> data locally to prevent unnecessarily hitting the web service. however,
>> this
>> is reporting data, so by nature it is changing frequently. the easiest
>> solution is to hit the web service every time. an alternative would be to
>> update a timestamp field for each report, updated via triggers, giving a
>> quick indication of whether the cached data was stale or not. however, as
>> the database contains hundreds of reports, many of which contain multiple
>> joins, this seems to be a nightmarish prospect to set up, and very error
>> prone. is this a common issue with smart client development? what steps
>> should i consider taking here?
>>
>>
>>
>

"Fidget Brain" <[NO~SPAM]martinthrelly@yahoo.com> wrote in message
news:OEAjapQMHHA.5016@TK2MSFTNGP04.phx.gbl...
> thanks for your advice. it all makes sense to me.
>
> "Buying the user small puzzles or sudoku books to keep them occupied
> while
> they wait for their reports."
>
> lol
>
> By this, do I take you to mean that smart clients look good on paper,
> but in practice run like a one legged horse?
>

Any application hitting a server for huge amounts of the data
will have the same problem. It doesn't matter if it's a
smart client, fat client, thin client, web service, etc.
It also depends a lot on the network being used to access
the data. At some companies I've worked for, the network
has been stellar and you could read/write thousands of records
without it being a problem, and at others, the same thing would
take days. >:-O

Robin S.