Data display? (Continued)

[Ben R.]

Since the original thread is marked as answered, I thought I'd post here to
ensure visibility.

Hi John and Steven,

I'm going the dataset route as access doesn't seem to be too keen on that
level of complexity in joins. Anyway, I'm curious as to why it makes more
sense to fill a datatable and then contsruct a new datatable from the first
one. Why not just create a datatable based off of a datareader? To be honest,
I'm not too familiar with the other method of accessing data through a data
table. I'm more used to a forward-only cursor. I invision enumerating through
the datareader and for each entry saying something like,

"If username doens't already have a datarow, create one. Now, add hours to
the appropriate column."

So it would create the row if necessary, and then in either case, would add
the hours. Is there a way to do this type of check? it would avoid the need
to enumerate through the datasource adding all the rows and then re-enumerate
through to add hours.

I guess I'm just not sure of how to enumerate through a datasource which
gives you this level of flexibility. My mental model has always invovled
working around the narrow confines of a foreward only cursor and not a random
access model. Any thoughts?

-Ben

[Steven Cheng[MSFT]]

Hi Ben,

Thank you for your further posting.

As for the new questions you mentioned, here are some of my understanding:

1. As for forward only and cursor based data access components, such as
datareader, the data reading should be performed during the lifecycle of
the datareader and connection. After we finishing using it, we should close
the reader and connection and next time we need to execute query and
establish connection again.... However, it won't occupy much application
memory

2. As for DataSet/DataTable, they're random accessable and do not rely on a
live server cursor and database connection. It is only when we query the
DataSet/DataTable do we need to open the connection. After we close the
connection ,the DataSet/DataTable still exists in our memory and we can
cache it to avoid unnecessary data accessing to backend database. And we
can directly access each DataRow in the DataTable through the
DataTable.Rows collection (by rowIndex).
In addition, DataTable also provides simple SQL- like query engine that can
help perform datarow querying depend on some simple query criteria:

#DataTable.Select Method (String)
http://msdn2.microsoft.com/en-us/library/det4aw50.aspx

BTW, here is a roadmap on ADO.NET which may also be helpful:

#INFO: Roadmap for ADO.NET
http://support.microsoft.com/?id=313590

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

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

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Ben R.]

Hi Steven,

Thanks for the response. I think I may not have been thorough in my
question, though. I actually do understand the fundamental differences
between how a datareader and datatable operate, but would like to understand
why it is suggested that I use a datatable rather than a datareader to solve
the problem I brought up previously in the thread "Data display?". To put it
otherwise, what does the random accessibility provide for me that I need?

Do you have any thoughts on this?

Thanks...

-Ben
"Steven Cheng[MSFT]" wrote:

Hi Ben,

Thank you for your further posting.

As for the new questions you mentioned, here are some of my understanding:

1. As for forward only and cursor based data access components, such as
datareader, the data reading should be performed during the lifecycle of
the datareader and connection. After we finishing using it, we should close
the reader and connection and next time we need to execute query and
establish connection again.... However, it won't occupy much application
memory

2. As for DataSet/DataTable, they're random accessable and do not rely on a
live server cursor and database connection. It is only when we query the
DataSet/DataTable do we need to open the connection. After we close the
connection ,the DataSet/DataTable still exists in our memory and we can
cache it to avoid unnecessary data accessing to backend database. And we
can directly access each DataRow in the DataTable through the
DataTable.Rows collection (by rowIndex).
In addition, DataTable also provides simple SQL- like query engine that can
help perform datarow querying depend on some simple query criteria:

#DataTable.Select Method (String)
http://msdn2.microsoft.com/en-us/library/det4aw50.aspx

BTW, here is a roadmap on ADO.NET which may also be helpful:

#INFO: Roadmap for ADO.NET
http://support.microsoft.com/?id=313590

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

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

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Thanks for your response Ben,

em... I think we still need to refer to the scenario mentioned in your
former thread. In your previous case, you need to perform some complex
structure data querying from an Access Database. However, access database
doesn't support as complex SQL scripts as SQL Server... Then, we can use
DataAdapter to query out data as DataTable and store them in DataSet. The
ADO.NET DataSet provide powerful local data manipulation functionality. For
example, we can query out multiple DataTables (which has relationship with
each other) and store them in the same DataSet, and then we can add
relationShip for them in the DataSet. Thus, the parent Table's DataRow can
reference its childTable's Rows through DataRow.GetChildRows....

This is just like a local database engine we can perform some data
manipulation among multiple local datatables in the DAtaSet without the
limitation of the backend database storage.

Regards,

Steven Cheng
Microsoft Online Community Support
==================================================

When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.

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

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)