G
Greg
Our DAL (Data Access Layer as a dll) is hosted by IIS. We use binary
serialization to pass a DataSet into the DAL from a client exe.
Our client exe calls GetChanges on DataSet and passes the changes to our
remoted DAL.
On inserts we have an output parameter for the primary key. After the call
to DataAdapter.Update, we watch the insert sproc run and return the output
param value. We watch the DataRow change from Added to Unchanged. We watch
the source column for output param get set to the outparam's value. The DAL
then returns the DataSet to the client exe.
Once back in the client exe, the DataRow is still marked as Added and the
source column is empty. This is exactly the way it looked when it was sent
to the remoted DAL.
Now, if we run the DAL locally in a private folder, we see the same results
in the DAL. However, back in the client exe the DataRow is marked as
Unchanged and the
source column contains the output parm value.
This leads me to believe there is a bug in the Remoting or ADO.NET
architecture.
serialization to pass a DataSet into the DAL from a client exe.
Our client exe calls GetChanges on DataSet and passes the changes to our
remoted DAL.
On inserts we have an output parameter for the primary key. After the call
to DataAdapter.Update, we watch the insert sproc run and return the output
param value. We watch the DataRow change from Added to Unchanged. We watch
the source column for output param get set to the outparam's value. The DAL
then returns the DataSet to the client exe.
Once back in the client exe, the DataRow is still marked as Added and the
source column is empty. This is exactly the way it looked when it was sent
to the remoted DAL.
Now, if we run the DAL locally in a private folder, we see the same results
in the DAL. However, back in the client exe the DataRow is marked as
Unchanged and the
source column contains the output parm value.
This leads me to believe there is a bug in the Remoting or ADO.NET
architecture.