Rick,

The Item property of a DataRow accepts a second optional parameter from the DataRowVersion enumeration. The DataRow has two “versions” — what’s currently stored in the row and what was originally stored in the row.

DataRow rowCustomer;
rowCustomer = ds.Tables["Customers"].Rows.Find("ALFKI");
rowCustomer["CompanyName"] = "NewCompanyName";
string strNewCompanyName, strOldCompanyName;
Console.WriteLine(rowCustomer["CompanyName", 
                              DataRowVersion.Current]);
Console.WriteLine(rowCustomer["CompanyName", 
                              DataRowVersion.Original]);

When you edit a row using BeginEdit and EndEdit, you might want to examine another version of the column: the “proposed” version. Once you call EndEdit, the changes will be stored in the current version of the row. Before then, however, the changes you make to the row will only be pending because you can still cancel the changes by calling CancelEdit.

While you’re editing a row, you can check the proposed view of a column by checking its Item property and supplying the Proposed constant from the DataRowVersion enumeration. Using the Current constant will return the value of the column before BeginEdit is called—which is not necessarily the original version of the column.

The fourth value for DataRowVersion is "Default". This Default value in the enumeration represents the default value for the parameter on the DataRow object’s Item property. If you’re not in the process of editing a row, calling Item and omitting the optional parameter is equivalent to supplying the DataRowVersion.Current constant for the optional parameter. However, if you’re in the process of editing a row and you omit the optional parameter on the Item property, you’ll receive the “proposed” version for the column.


>What does that actually do?
>(Too lazy (or busy? <g>) to look at this this second).
>
>+++ Rick ---
>
>
>>Hey Rick,
>>
>>I was just poking around in the docs and noticed that DataRow's have a DataRowVersion enumeration.
>>
>>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconrowstates.asp
>>
>>One of the possible values is DataRowVersion.Default, which looks promising. I'm not sure if all back-ends support this. It looks like there is a HasVersion() method that can be used to check. I haven't found any code examples, however.
>>
>>-- Randy
>>
>>>I agree to a large degree. But it's a shame that this behavior exists and we can't control it. Default values in the database can greatly simplify this behavior and reduce the amount of client code that has to run.
>>>
>>>As I mentioned I have this partially fixed with a flag on my BO which can automatically fill everything with blanks. This at least lets me handle the 90% case automatically only occasionally requiring a manual override in the BO code...
>>>
>>>For real business type logic (rather than a simplistic default value) I would always choose to put defaults into the bus object.
>>>
>>>I'm in general not a strong believer in putting too much logic into the database even if it does provide better performance in many cases. It's just more consistent with an OO architecture to have this logic in the BO layer of the app.
>>>
>>>
>>>+++ Rick ---
>>>
>>>
>>>>Hi Rick,
>>>>
>>>>>Right now as it stands I have a routine that initializes most values to
>>>>>non-null values then explicitly follow up the fields that need to have
>>>>>specific values (or null) set. It's not a big deal, but this sort of thing seems very inefficient requriing lots of extra code... (well actually my BO has some code that can do this automatically setting everything to VFP style blanks rather than nulls).
>>>>
>>>>I don't have an answer w.r.t. ADO.net, but in general I've been concluding lately that default values ideally should not even be under the control of the back-end, but rather should be controlled by the BO in the first place. Well, at least whenever you have control over both tiers...
>>>>
>>>>>Dealing with NULLS in ADO.NET is a PITA too because you have use DBNull for all comparisons etc. so I'm even less inclined to ever use NULLs in any data except those that REALLY require it for knowledge of previously unset values (most don't).
>>>>
>>>>In a way, I have the same feeling about NULLS as default values. The BO really needs to make these calls. Of course, you have to do something in the backend to allow NULLs, but beyond that, I really want my BO to control this stuff rather than being faced with the anguish having my data-access strategy limit what I "know" about my data entities.
>>>>
>>>>-- Randy