DataAdapter

  • Thread starter Thread starter Jim Heavey
  • Start date Start date
J

Jim Heavey

Hello, Is it correct to say that if I am going to be updating 5 tables in a
SQL database, I should use 5 dataAdapters? I can use a single DataSet, but
should/must use 5 dataAdapters.

If that I true, the I would never want to create a single Procedure which
would return 5 answer sets. I was looking at the ability to execute a
single Procedure and use the :TableMapping method of the DataAdapter.
Since there is only a single "UpdateCommand" associated with a dataAdapter,
then by definition, each table must have its' own dataAdapter.

Is that correct?

If my tables were "read only" then I could use a single DataAdapter with a
single Procedure which would bring back the 5 tables and this is where I
would use the TableMappings method? Is that correct?

Thanks in advance for your assistance!!!!!!!!
 
Jim Heavey said:
Hello, Is it correct to say that if I am going to be updating 5 tables in a
SQL database, I should use 5 dataAdapters? I can use a single DataSet, but
should/must use 5 dataAdapters.
Indeed.

If that I true, the I would never want to create a single Procedure which
would return 5 answer sets. I was looking at the ability to execute a
single Procedure and use the :TableMapping method of the DataAdapter.
Since there is only a single "UpdateCommand" associated with a dataAdapter,
then by definition, each table must have its' own dataAdapter.

Is that correct?
Click to expand...

Second point for you :)
If my tables were "read only" then I could use a single DataAdapter with a
single Procedure which would bring back the 5 tables and this is where I
would use the TableMappings method? Is that correct?
Click to expand...

It is better (as by recommendation) that you create a dataadapter for each
table.
Anyway, you could just swap selectcommands or just their commandtext
property.
You even don't need table mapping as you can pass a DataTable as Fill
parameter.
 
Jim,

I'll disagree with part of what Miha says here. The DataSet is an _entirely_
disconnected entity. Unless you're using the CommandBuilder (which has other
problems) there is absoltuely no reason you need to update/insert/delete
data from the same data adapter that you used to retrieve the data. It works
quite well to retrieve multiple SQL resultsets as multiple tables via a
single stored procedure, then update the data using a separate data adpater
for each table as Miha suggested. The benefit is to reduce the traffic, and
in many cases where the retrieval is complicated, significantly reduce the
complexity of the stored procedures.

Kathleen
 
Hi Kathleen,

Kathleen Dollard said:
Jim,

I'll disagree with part of what Miha says here. The DataSet is an _entirely_
disconnected entity. Unless you're using the CommandBuilder (which has other
problems) there is absoltuely no reason you need to update/insert/delete
data from the same data adapter that you used to retrieve the data. It works
quite well to retrieve multiple SQL resultsets as multiple tables via a
single stored procedure,
Click to expand...

Of course. There are infinite possibilities with ADO.NET.
I just suggested the most common which is also supported by design time
wizards.
BTW, do you think that retrieving batch datatables is significantly faster
(or less network traffic?).
I haven't tested it yet but I think the speed gain versus flexibility of
select per table is too small.
 
Back
Top