Is this a hokey fix?

  • Thread starter Thread starter headware
  • Start date Start date
H

headware

I have written a function that takes a few rows out of a table and
returns them in a DataSet. It looks roughly like this

[WebMethod]
public DataSet GetSomeRows()
{
OleDbDataAdapter da = new OleDbDataAdapter("SELECT * FROM MyTable",
conn);
DataSet ds = new DataSet();
da.Fill(ds);

DataTable newTable = ds.Tables[0].Clone();

foreach(DataRow row in ds.Tables[0].Rows)
{
if(/* some criteria is met */)
{
DataRow newRow = newTable.NewRow();
newRow.ItemArray = (object[])row.ItemArray.Clone();
newTable.Rows.Add(newRow);
}
}

DataSet newDS = new DataSet();
newDS.Tables.Add(newTable);
return newDS;
}

I have to encapsulate the DataTable in a DataSet before returning it
because this function is actually a web service and web services will
return DataSets but not DataTables.

All that works fine and well. The problem is that in some instances I
want to take the DataSet that results from calling the function,
change some of the data in the rows, and update the database. I can't
do that because the row states for the DataSet are all
DataRowState.Added and when I call the Update() method it tells me
that I'm trying to add duplicate primary key values, which I guess is
true.

What I did to "fix" the problem was to call AcceptChanges() on the
DataSet after the function call returned in. Then it allowed me to
change the rows and only update the database with those changes.

My question (finally) is this: Is that fix a good idea or just a hack?
Is there a more ADO.NET Approved way of doing what I'm trying to
accomplish? It seems a little questionable to me.

Thanks,
Dave
 
Hi,

No, you are doing it the right way.
Better solution would be to add a WHERE clause to your select (using
parameters if possible) and just invoke ds.Fill.
Way faster.
 
Thanks for the help. Unfortunately, due to the nature of the problem,
using a WHERE clause hasn't proved to be a viable option.

Dave

Miha Markic said:
Hi,

No, you are doing it the right way.
Better solution would be to add a WHERE clause to your select (using
parameters if possible) and just invoke ds.Fill.
Way faster.

--
Miha Markic [MVP C#] - RightHand .NET consulting & development
miha at rthand com
www.rthand.com


headware said:
I have written a function that takes a few rows out of a table and
returns them in a DataSet. It looks roughly like this

[WebMethod]
public DataSet GetSomeRows()
{
OleDbDataAdapter da = new OleDbDataAdapter("SELECT * FROM MyTable",
conn);
DataSet ds = new DataSet();
da.Fill(ds);

DataTable newTable = ds.Tables[0].Clone();

foreach(DataRow row in ds.Tables[0].Rows)
{
if(/* some criteria is met */)
{
DataRow newRow = newTable.NewRow();
newRow.ItemArray = (object[])row.ItemArray.Clone();
newTable.Rows.Add(newRow);
}
}

DataSet newDS = new DataSet();
newDS.Tables.Add(newTable);
return newDS;
}

I have to encapsulate the DataTable in a DataSet before returning it
because this function is actually a web service and web services will
return DataSets but not DataTables.

All that works fine and well. The problem is that in some instances I
want to take the DataSet that results from calling the function,
change some of the data in the rows, and update the database. I can't
do that because the row states for the DataSet are all
DataRowState.Added and when I call the Update() method it tells me
that I'm trying to add duplicate primary key values, which I guess is
true.

What I did to "fix" the problem was to call AcceptChanges() on the
DataSet after the function call returned in. Then it allowed me to
change the rows and only update the database with those changes.

My question (finally) is this: Is that fix a good idea or just a hack?
Is there a more ADO.NET Approved way of doing what I'm trying to
accomplish? It seems a little questionable to me.

Thanks,
Dave
Click to expand...
Click to expand...
 
Back
Top