Apply DataAdapter to non-filled DataTable

[news.microsoft.com]

Can someone please help me understand how you go about applying a
DataAdapter to a DataTable that was not "Filled" but populated by, say, a
DataReader???

Thank you.

 

[Scott M.]

If you have data in a DataTable and intend to update the original data
source, then you should have used a DataAdapter in the first place, rather
than a DataAdapter.

A DataReader would be best for times when you don't plan on modifying the
data (and therefore wouldn't need a DataAdapter).

 

[William \(Bill\) Vaughn]

First, change the account you're using to show your name instead of
"news.microsoft.com" so we have an idea who we're dealing with.
Next, if you create a DataTable with a DataReader, you're wasting a lot of
time as this can be done far more efficiently with a DataAdapter Fill
method.
Ok so you chose to ignore this advice. You still need to setup the
DataAdapter with the 3 Commands used to update the data--the UpdateCommand,
InsertCommand and DeleteCommand. These can be written manually or you can
get the DataAdapter configuration Wizard to do this for you. You can also
use the CommandBuilder (but see my article on the CommandBuilder before you
do). http://www.betav.com/msdn_magazine.htm

I describe how to do all of this in my book.

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

 

[news.microsoft.com]

Bill,
Ok, so i changed my name.

Second, I agree that the Fill method is simple for returning data. But,
keep in mind that the Fill method USES the DataReader to execute the fill.
So actually, the DataReader is the most direct and fasted way to retreive
data compared to Fill. My thought was in cases where I would like to use
the DataReader to fill a DataTable for spead but then apply a DataAdapter to
the table to update the datasource.

Thus my question,
Can a DataAdapter be applied to a table populated under this scenario?

 

[Scott M.]

I might not have been as clear as I should have in my original reply to your
post:

If you know you are going to need a DataAdapter (because you plan on
modifying data in the original data source), then you should skip the use of
the DataReader and just use a DataSet in conjunction with a DataAdapter.

In the end, you'll wind up using less resources.

 

[news.microsoft.com]

Thanks for the input Scott.
Assuming it is possible to add a DataAdapter after a table is populated via
DataReader... How is it that using the DataAdapter from the get go uses less
resources applying it later?

 

[TJO]

Ok, now my name is changed.

 

[Scott M.]

If you will need to modify data then you need:

A Connection
A Command
A DataAdapter (the command can be set up explicitly or you can use the
integrated commands in the DA)
A DataSet (this contains a DataTables collection)

You're going to need these objects for data modification anyway. You are
proposing adding a DataReader to this list, which is not necessary for what
you are trying to do and would add an additional object.

 

[William \(Bill\) Vaughn]

Ah no. (and your name is still "news.microsoft.com".)
If you intend to create a DataTable, there is no faster way than to use Fill
(not until Whidbey). Using a DataReader and extracting the rows into a
DataTable is (by several folk's tests) 3 to 7 times slower than using Fill.
A DataAdapter can be applied to ANY DataTable--regardless of where it comes
from.

hth

--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

 

[TJO]

Bill, I don't at all mean to argue. But every book I have read and every
speaker I have heard all indicate that the Fill is slower than the
DataReader because the Fill uses the DataReader. I am very glad to hear you
say otherwise because the Fill is more convenient.

 

[Scott M.]

Why would a DataReader be slower than a DataReader?

 

[William \(Bill\) Vaughn]

The point is, if you know how to use a DataReader, use it. It's interesting
to return a rowset when you DON'T need a DataTable and its features. Fill is
overkill for lots of queries and essential when you want ADO.NET to expose
the Update method. (See my article
http://www.pinpub.com/html/main.isx?sub=45&query=command+vaughn) We've seen
too many folks extol the virtues of the DataReader only to turn around and
write fifty lines of code to parse the columns that come back and then write
another n lines to build a DataTable from the rowset. Each of those lines of
code have to be debugged and tested and are subject to change when the
schema changes. Madness.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________

 

[TJO]

I tend to agree.

Thanks Bill

The point is, if you know how to use a DataReader, use it. It's interesting
to return a rowset when you DON'T need a DataTable and its features. Fill is
overkill for lots of queries and essential when you want ADO.NET to expose
the Update method. (See my article
http://www.pinpub.com/html/main.isx?sub=45&query=command+vaughn) We've seen
too many folks extol the virtues of the DataReader only to turn around and
write fifty lines of code to parse the columns that come back and then write
another n lines to build a DataTable from the rowset. Each of those lines of
code have to be debugged and tested and are subject to change when the
schema changes. Madness.
--
____________________________________
William (Bill) Vaughn
Author, Mentor, Consultant
MVP, hRD
www.betav.com
Please reply only to the newsgroup so that others can benefit.
This posting is provided "AS IS" with no warranties, and confers no rights.
__________________________________