Performing a Load after DML Statements

[paul-esposito]

Okay, so I'm the DBA not a developer, but I need a sanity check. All the
data access to the database is controlled by Stored Procedures, the
procedures are really granular, basically every table has an
<tableName>Insert, <TableName>Update, <TableNameLoad ... procedure. My
question is this, the <TableName>Update and <TableName>Insert all contain a
call to <TableName>Load, as the last statement in the procedure. My initial
reaction is why would we do that, we just wrote the thing, and the reply from
the .NET developers is that we do this because we need to refresh the dataset
within .NET to say that it is committed. I asked why not just do a select of
the @variables passed into the proc to simulate the load, and the answer to
that was the coding issues of keeping that select in synch with the select
from the <tablename>Load proc, plus there are always parameters that are
defaulted (CreateDate, UpdateDate, UserID....), that would need to be
defaulted in the proc versus letting the database do it and getting it on the
Load. Hopefully I described our environment well enough to give you guys an
idea of our situation.

My question is this, does it make sense to do a Load after every DML
statment to refresh the .NET dataset?

[Brendan Green]

If specific values were being updated in the table by, say, a trigger or a
default, then your DataSet
will be out-of-sync with the underlying database table.

So the answer to your question is sometimes, but it depends on the scenario.

"paul-esposito" <pa***********@discussions.microsoft.com> wrote in message
news:5E**********************************@microsof t.com...

Okay, so I'm the DBA not a developer, but I need a sanity check. All the
data access to the database is controlled by Stored Procedures, the
procedures are really granular, basically every table has an
<tableName>Insert, <TableName>Update, <TableNameLoad ... procedure. My
question is this, the <TableName>Update and <TableName>Insert all contain
a
call to <TableName>Load, as the last statement in the procedure. My
initial
reaction is why would we do that, we just wrote the thing, and the reply
from
the .NET developers is that we do this because we need to refresh the
dataset
within .NET to say that it is committed. I asked why not just do a select
of
the @variables passed into the proc to simulate the load, and the answer
to
that was the coding issues of keeping that select in synch with the select
from the <tablename>Load proc, plus there are always parameters that are
defaulted (CreateDate, UpdateDate, UserID....), that would need to be
defaulted in the proc versus letting the database do it and getting it on
the
Load. Hopefully I described our environment well enough to give you guys
an
idea of our situation.

My question is this, does it make sense to do a Load after every DML
statment to refresh the .NET dataset?