Updating Dataset Column Value ...

[hauschild]

Guys,

I am looping thru a dataset and need to update rows' columns based on the ColumnName value. I get this far but I'm unsure of how to update that actual columns value with the new value. Code follows:

string sDate = (Thread.Current Thread.CurrentC ulture.DateTime Format.ShortDat ePattern.ToStri ng());

string BritishDate;
string USDate;

if (sDate != "MM/dd/yyyy")
{
foreach (DataRow drItemPlan in dsItemDemand.Ta bles[0].Rows)
{
BritishDate = drItemPlan["exp_date"].ToString();
USDate = DateTime.Parse( BritishDate).To String("MM/dd/yyyy");

foreach (DataColumn col in dsItemDemand.Ta bles[0].Columns)
{
if (col.ColumnName == "exp_date")
{
//UPDATE THE COLUMN VALUE TO EQUAL USDate
}
}

}
}


I'm new to C# and I'm having some issues with the fact a dataset is an object and how to then maniuplate that object's column and/or row values.

Thanks.

[nateraaaa]

if (sDate != "MM/dd/yyyy")
{
foreach (DataRow drItemPlan in dsItemDemand.Tables[0].Rows)
{
BritishDate = drItemPlan["exp_date"].ToString();
USDate = DateTime.Parse(BritishDate).ToString("MM/dd/yyyy");
//you will need to call an update stored procedure to update the the value in the database. Pass USDate to the proc as a parameter and update the exp_date value for each row.
}
}

Nathan

[hauschild]

The application has a back end handled by a Progress database. The current dataset gets built as a user builds an Infragistics grid of data records.

What I need to do is update the value of the date field in the dataset so that it doesn't blow up the back end code - which it does now.

I am beginning to wonder if it isn't possible to update a dataset that already contains data and whether I should maybe base this entire process off looping thru the records in the grid versus looping thru the records of the dataset - or create a new record with the new value while deleting the old one.

[hauschild]

Guys,

I figured something out which works so far, although I'm certainly not experienced enough in the realm of C# to know if what I've created is actually accurate and almost as importantly, efficient. Here is what I did:

string sDate = (Thread.Current Thread.CurrentC ulture.DateTime Format.ShortDat ePattern.ToStri ng());

foreach (DataRow drItemPlan in dsItemDemand.Ta bles[0].Rows)
{
string CanuckDate = drItemPlan["exp_date"].ToString();

System.Threadin g.Thread.Curren tThread.Current Culture = new System.Globaliz ation.CultureIn fo("en-CA");
DateTime dtCanuckDate = Convert.ToDateT ime(CanuckDate) ;

System.Threadin g.Thread.Curren tThread.Current Culture = new System.Globaliz ation.CultureIn fo("en-US");
dtCanuckDate = Convert.ToDateT ime(dtCanuckDat e.ToShortDateSt ring());

dsItemDemand.Ta bles["ttitem_pla n"].Rows[i]["exp_date"] = dtCanuckDate;
i++;
dsItemDemand.Ac ceptChanges();

}


Maybe this will help somebody else who is new to C#.

I shoudl also add why I needed to do this. Basically, the back end database is Progress, which was installed on the clients' machines in M/D/Y format(at least my guess). As a result, all date types would be expecting mm/dd/yyyy. A day like today (march 21, 2008) would make it choke because the front end would be sending 21/3/2008 (standard Canada date format) - Progress expects there to be a numberic value between 1-12 in the first two byte postions, but obviously 21 is greater than 12, hence the minor mushroom cloud and a failed database update. Reinstalling Progress was not an option, so this was the option that made the most sense. The only probelm with this route is that every screen of our app (while not many) which may see a user updating a date value will need to be addressed.