My users have been reporting since yesterday that dates they enter into the WebDataGrid are losing a day when saving to the database.
On closer inspection, these date/time fields are losing 1 hour. For example, if a user enters 11/7/2011 into the WebDataGrid, 11/6/2011 11:00PM will be stored to the database, and the users then sees 11/6/2011 displayed in the grid as his saved value. This occurs regardless of the EditorProvider used... This even happens if you use the TextBox provider.
And this began recently, oddly corresponding to Daylight Savings Time.
I have found a very clumsy workaround. If you change your SQL statement so that it converts DateTime fields to VarChars, the WebDataGrid won't corrupt the date.
I have opened a support ticket CAS-77072-NSTXZT, but have also posted the issue and the workaround here, for the benefit of other users.
I consider this issue to be critical, since it is corrupting data.
I am very lucky that my application doesn't call for storing time values.
Have you submitted a ticket so that they know about the issue that persists with time values?
The same happens to time columns, but for some reason, the date value of the time is changed. Arghh! Quite frustrating. Will have to strip out the time portion in javascript and compare them to see if they really changed! Just tabbing through a time field, the _Editing_CallValueChanging() event has these values:
? eventArgs.get_currentValue().toString()
"Wed Nov 30 10:21:00 PST 2011"
? eventArgs.get_newValue().toString()
"Thu Nov 10 10:21:00 PST 2011"
Very odd that webdatagrid chose to change the date portion of the time column form Nov 30 to Nov 10. Happens to be my wife's birthday!
They still need to do some more work on the date and time column editing.
One side effect I have noticed is that for date columns, the CellValueChanged Event gets triggered by just tabbing through a date field.
Evaluating the _Editing_CellValueChanging event, the eventArgs.get_currentValue() and eventArgs.get_newValue() are equal. I imagine this is a side effect of the change that was made.
I am currently using this code to bypass this behavior
function
wdg_Editing_CellValueChanging(sender, eventArgs) {
if (eventArgs.get_currentValue().toString() == eventArgs.get_newValue().toString())
eventArgs.set_cancel(
true);
}
Thanks for reporting back! Glad to hear it!
Just wanted to confirm that I upgraded to 11.2 and this is no longer an issue.
Thanks
Jorge