Before I start I want to say that I am a newbie to .NET and C# and want to
relay my observation about C# and it's data mechanics.
I may be wrong in my observations, and if so, PLEASE correct me and point me
in the right direction.

Also I may be new to .NET, I have been programming in C++ and SQL for 15
years.


Why has .NET built it's data consumption around DataTables?

Aren't DataTables "really" designed to gain access to data in 1 table?

I have been building commercial applications for about 15 years and I have
never (that I can remember) only needed to use only 1 table.
Especially if it's data that the end user will see and manipulate.

It seems like this DataTable concept has just done away with 80% of the
power of SQL.
The DataTables and DataSet doesn't give you any "true" flexibility in how
YOU the developer want to handle your data.

How can you use JOINS or any other multi-table SQL dialect with DataTables
and allow your end-user to change that data and then have it written back to
the database correctly?

I will admit, I haven't tried this, because I'm away and can't get to an
IDE.
I just reading varies MS .NET books and they ALL deal with DataTables and
all of the examples are using single-table SQL statements.

Please help and tell that this is not the case.

Thanks

Instead of thinking of a DataTable as being related to a SQLS table,
think of it as a client-side cache, and it makes more sense. You have
to use a DataAdapter to talk to your server-side tables for fetching
data into your DataTable client-side cache and for posting back data
modifications.

As far as data modifications go, single-table updates are the norm for
SQL Server--you can't update both sides of a join at once anyway. You
can specify update statements or the name of a stored procedure to use
when updating data from your DataTables. Here's a good introductory
article:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon/html/vbconfundamentaldataconceptsinvisualstudionet.asp.

ADO.NET was designed to handle the scaling needs of n-tier
applications, moving away from the 2-tier model of holding on to
connections and pessimistic locking for handling multi-user
concurrency issues. You'll find a lot of things are radically
different as you dig in a bit more. HTH,

--Mary

On Fri, 1 Sep 2006 03:16:02 -0700, "Relaxin" <me (AT) yourhouse (DOT) com> wrote: