Design issue: Preload data or get on request

[Frustrated Newbe]

Hi,

I would appreciate your opinion on the following issue. Suppose there is a
windows (not web!) application that uses the data stored on an SQL server.
There can be more than one concurrent user of the app, so the concurrent
database update is an issue. There are also plenty of forms that when
displayed have some or all controls pre-filled with data, which is stored in
a number of different tables in the database. Question: what approach is
better in this case - preload the data and store it in a dataset and only
actually connect to the DB at the initial load and when insert/update is
required or load the data for each user request and not maintain any cache.
The number of records in question will be in hundreds rather than thousands
and the app is designed to run on WinXP.

--
Thanks.

[Nick Malik [Microsoft]]

pre-query the domain tables (lookup tables where the data rarely changes).
Look up anything and everything else on the fly (using stored procedures),

--- Nick

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Frustrated Newbe" <Fr*************@discussions.microsoft.com> wrote in
message news:A6**********************************@microsof t.com...

Hi,

I would appreciate your opinion on the following issue. Suppose there is
a
windows (not web!) application that uses the data stored on an SQL server.
There can be more than one concurrent user of the app, so the concurrent
database update is an issue. There are also plenty of forms that when
displayed have some or all controls pre-filled with data, which is stored
in
a number of different tables in the database. Question: what approach is
better in this case - preload the data and store it in a dataset and only
actually connect to the DB at the initial load and when insert/update is
required or load the data for each user request and not maintain any
cache.
The number of records in question will be in hundreds rather than
thousands
and the app is designed to run on WinXP.

--
Thanks.

[in]

Frustrated Newbe wrote:

Hi,

I would appreciate your opinion on the following issue. Suppose there is a
windows (not web!) application that uses the data stored on an SQL server.
There can be more than one concurrent user of the app, so the concurrent
database update is an issue. There are also plenty of forms that when
displayed have some or all controls pre-filled with data, which is stored in
a number of different tables in the database. Question: what approach is
better in this case - preload the data and store it in a dataset and only
actually connect to the DB at the initial load and when insert/update is
required or load the data for each user request and not maintain any cache.
The number of records in question will be in hundreds rather than thousands
and the app is designed to run on WinXP.

I'm working on the same problem right now.

The design I'm choosing is:

1. Use a web service to send the client an XmlDocument at first load.
2. Set up WSE 2.0 to send notifications of changes to the document to
the server and all the clients using messaging.
3. Occasionally refresh the database with the most current changes to
the XML document at the web service server.

[Nick Malik [Microsoft]]

Why are you using a web service on top of a database as part of the
middleware of an application?

This is sometimes called for, but not usually.

Don't get me wrong... I'm no enemy of web services. I'm a serious proponent
of SOA when used correctly. One of my systems uses a web service between a
client and the db server. However, in that case, the system is designed to
support a variety of clients, and the web services have functionality that
goes far above and beyond simple DB calls. Therefore, you could say that
the web services form an external interface, and that I'm delivering more
than one application in my system.

On the other hand, the OP suggested a situation that clearly does NOT call
for a WS. You chimed in that you are doing the same thing, and, from what I
can tell, you are right... you have the same concerns... but your solution
is less efficient, with more points of failure, and more points of attack
(security). You even appear to have added a broadcasting component (a rare
thing, considering the fact that it is usually more of a problem than a
solution).

Is there a reason for the overhead? What constraints in your system led you
to such an odd and expensive design?

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"in" <gu*****@treeview.control> wrote in message
news:38*************@individual.net...

I'm working on the same problem right now.

The design I'm choosing is:

1. Use a web service to send the client an XmlDocument at first load.
2. Set up WSE 2.0 to send notifications of changes to the document to the
server and all the clients using messaging.
3. Occasionally refresh the database with the most current changes to the
XML document at the web service server.

[Cor Ligthert]

Hi,

It all depends what application you are after,

If it is for a bank, to process by instance all on line actions from the
clients, than definitely there is another approach needed than when it is
for a school, where the children are getting information about history from
a database.

Just my thought,

Cor