Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>The code you have posted looks fine. My test code is almost identical to yours, but I cannot produce the unwanted results you are seeing. </p> <p>The most significant difference between your code and mine is that I don't have the code for your master page. My master page is the default page created by VS 2008. Other than that, the differences are in the SQL and the underlying database. Specifically, I am not using any stored procedures, and I have made reasonable assumptions about the data types involved: the <code>ID</code> is <code>int</code>, <code>Status</code> is <code>smallint</code>, <code>SheetDate</code> is <code>Date</code>, <code>DateUpdated</code> is <code>DateTime</code>, and everything else is <code>varchar</code>. </p> <p><strong>EDIT:</strong> Your <code>SheetDate</code> appears to be just the date portion of an underlying <code>DateTime</code> value from the database. The fact that your query transforms the underlying data value for display purposes is not relevant, because the grid view can't tell that it is getting a modified value. <strong>END OF EDIT</strong></p> <p>Here are a few suggestions for diagnosing the problem:</p> <ul> <li><p>Test without master page, or with a very simple dummy master page that is guaranteed not to have scripts that interact with the <code>BulkEditGridView</code>. Since the <code>ToolkitScriptManager</code> is apparently on your master page, you will need to either move the script manager control to the page itself, or else temporarily get rid of the <code>CalendarExtender</code> element, which requires the script manager.</p></li> <li><p>Temporarily replace the <code>Status</code> template field with a bound data field, to eliminate possibility of interaction with the <code>DropDownList</code>. The drop down list did not cause problems in my tests, but there may be subtle differences between your code and mine.</p></li> <li><p>If neither of these help, then a possible cause is a problem in your version of the <code>BulkEditGridView</code>.</p></li> </ul> <p><strong>EDIT - Additional suggestions for diagnosis:</strong></p> <ul> <li><p>Based on examination of the source code for <code>BulkEditGridView</code>, it appears that the code is properly tracking which rows of the grid are "dirty". Therefore, the most likely cause of a spurious dirty row is that one or more controls in the grid are incorrectly detecting a change to their data content. You can detect this in the debugger, using the source code for <code>BulkEditGridView</code>, rather than the pre-compiled DLL.</p></li> <li><p>Set a breakpoint at the start of <code>HandleRowChanged</code>, the event handler which detects changes in any cell of the grid. By examining the <code>sender</code> parameter of that object in the debugger, you can tell which controls in the grid are undergoing value changes. In particular, you will be able to tell which controls, if any, are incorrectly triggering a value change event. </p></li> <li><p>Once you determine which control(s) are incorrectly reporting that their value has changed, you can focus on <strong>why</strong> this is happening.</p></li> </ul> <p><strong>END OF EDIT</strong></p> <p>Some other suggestions to improve the code are as follows. <strong>These will not solve the original problem</strong>, but will make the code cleaner:</p> <ul> <li><p>In all of the template fields, remove the <code>ItemTemplate</code>s. They can never be used, since the <code>BulkEditGridView</code> forces every row to be in the edit state. </p></li> <li><p>In the code behind, the <code>BindData()</code> call is not needed, since the source data is specified in the declarative markup, and therefore the grid view control will automatically bind the data.</p></li> </ul>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload