G
Guest
I know this has been asked several times before, but...
Q: How can I fill multiple tables in a Dataset using a SINGLE .Fill?
Assume I have three tables in the data source - T1, T2 and T3 - that are
related "hierarchially" by FK's: T1 <--FK T2 <-- FK T3 The keys are
SQL2K auto-numbered "identity" columns.
I need to populate my Dataset with one row from T1 and its related child
rows from T2 and T3. Obviously, I can do this by invoking .Fill three times,
but that seems inefficient...
I've read posts that say to use a stored procedure to return three result
sets. OK, but how could a stored procedure EFFICIENTLY do this? When it
selects the row from T1, it will need to interrogate the returned identity
column in order to use it to select from T2 (and so-on and so-on). It could
use temp tables (or table variables), but this really seems to be a lot of
work to do something that could be done with a simple JOIN.
===> IMHO, it seems that .Fill needs to be able to populate multiple tables
in the Dataset FROM A SINGLE RESULTSET. If this were possible, then we could
just use a single SELECT with a JOIN (with or without a stored procedure).
It seems like we're introducing complexity (and more resource usage) into
the SQL "side" in order to workaround a limitation of ADO.NET...
...or have I totally missed something here?
DT
Q: How can I fill multiple tables in a Dataset using a SINGLE .Fill?
Assume I have three tables in the data source - T1, T2 and T3 - that are
related "hierarchially" by FK's: T1 <--FK T2 <-- FK T3 The keys are
SQL2K auto-numbered "identity" columns.
I need to populate my Dataset with one row from T1 and its related child
rows from T2 and T3. Obviously, I can do this by invoking .Fill three times,
but that seems inefficient...
I've read posts that say to use a stored procedure to return three result
sets. OK, but how could a stored procedure EFFICIENTLY do this? When it
selects the row from T1, it will need to interrogate the returned identity
column in order to use it to select from T2 (and so-on and so-on). It could
use temp tables (or table variables), but this really seems to be a lot of
work to do something that could be done with a simple JOIN.
===> IMHO, it seems that .Fill needs to be able to populate multiple tables
in the Dataset FROM A SINGLE RESULTSET. If this were possible, then we could
just use a single SELECT with a JOIN (with or without a stored procedure).
It seems like we're introducing complexity (and more resource usage) into
the SQL "side" in order to workaround a limitation of ADO.NET...
...or have I totally missed something here?
DT