Hi Bill,
Well, thank you very much for your reply. 30 minuites after reading it I
had resolved the issue. Clarified and recitified my thinking on the subject.
I think the core of my problem was that I was treating DataView/DataTable
relationship the same way I treat the DataSet/Database relationship.
Basically, as a disconnected relationship. Even though I've read and been
told the DataView automatically updates its DataTable, somehow it wasn't
registering.
Because I had that custom combobox GridColumnStyle, I had it wired for an
event ("DataUpdated") which fired when the combobox fired its
selectionchangecomitted. This bubbled up to my form and I made an event
handler to do the database update. I was sure this would work. But when I
put in the Debug.Assert statements you recommended, I found the event was
firing before the DataTable was changed and so the Database wasn't being
updated.
I realised I don't understand the whole edit/commit process down in that
DataGridStyle, so I fiddled with it, trying to call my custom-built
DataUpdated event from different places in the code (the combobox's
SelectedIndexChange, the datagridstyle's Commit, etc) and I realized I was in
over my head.
After putting in your Debug.Assert statements, and testing for the
DataSet.HasChanges property, I realised the DataTable as a RowChanged event.
So I tore out my custom event for my custom GridColumnStyle. I left the
DataView, CurrencyManager, and DataTable to run on their default behaviours
and just added a handler for the DataTable.RowChanged event which called my
UpdateDatabase procedure, and that resolved the issue.
I blame my ASP background; this is my first foray into Windows forms, and I
lack some basic familiarity with the object model. I really appreciate your
help resolving the issue. My next assignment is to work on understanding that
edit/commit process in the controls...
Thanks again,
Darryl.
"W.G. Ryan MVP" wrote:
> If you're using DataBinding, then as soon as you change the value through UI
> controls and the edit is finished, the value in the underlying table is
> changed. If you've 'changed' the value in the dataview, you've changed it
> in the datatable - it may appear otherwise but if the value was actually
> changed in the view, then it's definitely changed in the datatable as well.
>
> So a few things: 1) How have you verified that the value is changed in the
> DataView? If you successfully changed it in the view, then it's changed in
> the DataTable. Typically, problems with the symptom you've described are
> caused by improperly referencing the row index (so the 'real' value was
> changed, but since you're referencing a different index, it looks like it's
> not changed). Another problem comes from changing the value in the
> DataTable, but not submitting the update successfully to the database...
> then another select query is performed which retrieves the values from teh
> DB. Since the values were changed in the datatable, but no successful
> update was performed, when you requery it, you lose all the values you have.
> 3) Make sure that you're not eating any exceptions and not notifiying
> yourself. If the update is going bad and you just eat the exception, then
> the problem is w/ the Update on the back end.
>
> As such, verify that hte row has changes RIGHT before you call update, and
> verify that there are no changes afterward.
>
> ie
> Debug.Assert(MyDataSet.HasChanges(), "There are NO changes available but we
> expect that there should be");
> MyDataAdaptger.Update(MyDataSet, "TableName");
> Debug.Assert(!MyDataSet.HasChanges(), "Ther are changes present and there
> shouldn't be");
>
> I'd throw in the assertions liberally before and after any of my 'edits' so
> that I verified that chagnes were present (now the second assertion will
> fail if you don't call update - so on your edits keep this in mind)
>
> Let me know the results of the assertions and we'll take it from there.
>
> Cheers,
>
> Bill
>
>
|