469,138 Members | 1,257 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,138 developers. It's quick & easy.

Need Clarification - Approaches to Database Querying

As I continue to read more about the benefits of database querying using
ADO.NET, I am having a more difficult time distinguishing what the best
approach to data retrieval is anymore.

When creating datasets in the Visual Studio.NET designer, Command objects
(Update, Insert, Delete) are automatically generated for you based off your
SelectCommand value. You then get the benefits of strong typing, which from
what I've seen so far are helpful in a limited sense - perhaps I've not seen
enough of it to give an accurate assessment, but the main benefit seems only
to be within codebehind (read: Intellisense) in VS.NET... but I digress.

It seems that creating datasets in the designer is of benefit for simple
queries (at least thats what the examples that I've read have led me to
believe). If you want to query using stored procedures or views, the benefit
of the Command objects are lost. But you have far greater flexibility in
your queries.

Now, lets assume that I want the Command object benefits, and instead
perform queries on datasets (versus using stored procs), using DataRelation,
DataTable, and DataView objects. I just do all my joins on the in memory
tables and boom - same results as a stored procedure. Keep these tables in
cache, and at the end of the day (or whenever is appropriate), commit
changes to the datasource.

Which is the "preferred" method? It seems very unwieldy, especially for the
enterprise, if you have tables with several million rows (I imagine the
tranasctional management nightmare scenario), put them in cache, let users
make modifications, then validate all the changes prior to updating the
datasource. Is it possible to get the benefits of the Command objects while
still using stored procs?

From a slightly confused reader ;)
Thanks


Jul 21 '05 #1
2 1215
Elliot,

I dont like to tell about prefered methods, when there was a prefered
method, than there would probably be no alternatives.

However this sentence of you did make me shudder.
Keep these tables in cache, and at the end of the day (or whenever is
appropriate), commit
changes to the datasource.

What you do if your computer get a power down or whatever, read your IIS log
to check what people have connected.

I think that as soon that you have a commited change of data, that you than
should update it to your database.

However just my thought,

Cor
Jul 21 '05 #2
Cor:

I agree. And I'm not suggesting that this is the right answer. I am just
trying to feel out a somewhat new technology by posing some "what if" type
questions.

Thanks.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:eZ**************@TK2MSFTNGP10.phx.gbl...
Elliot,

I dont like to tell about prefered methods, when there was a prefered
method, than there would probably be no alternatives.

However this sentence of you did make me shudder.
Keep these tables in cache, and at the end of the day (or whenever is
appropriate), commit
changes to the datasource.
What you do if your computer get a power down or whatever, read your IIS

log to check what people have connected.

I think that as soon that you have a commited change of data, that you than should update it to your database.

However just my thought,

Cor

Jul 21 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Elliot Rodriguez | last post: by
2 posts views Thread by Sue | last post: by
7 posts views Thread by Jelle de Jong | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
1 post views Thread by Mortomer39 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.