I'm having trouble loading an UltraGrid.
I'm loading it in a thread (There is potentially tens of thousands of records to be loaded into the grid),displaying the current records every 100 records.
I'm getting the error above when I do this. The grid dissapears and is replaced with a big red cross, and a message box pops up with this message in it (I'll spare copying and pasting the whole thing right now).
I have seen this error reported elsewhere in the forums, and the reply seems to be along the lines of "are you using the latest hotfix" and "Could you make a small sample and give it to support". Just to beat you to the punch, I am using the latest version (I was using v8.1, but upgraded to v8.2 and applied the latest hotfix 2022 in an attempt to fix it.
I'm thinking its not my coding - I have done this elsewhere in my application and it works fine. What is also weird is that I cant see anything different about the record it stops on (Yes I have found the exact record it stops on), and the record it stops on changes from time to time (usually after making changes to the sequence of coding).
Can anyone tell me whats going on here? Is this a coding fault on my behalf? Or an Infragistics bug?
---- EDIT -----
Just to be clear here - there is nothing wrong with the data. If I load the data in a similar way, but store it all in a list, and then assign this list to the grids datasource at once (rather than adding the newly retrieved records to the existing datasource), it works fine. I only get this error when adding more and more records to a grid which already has data in it.
Hi fweeee,
I doubt this has anything to do with a hot fix or a bug in the grid. The big red X most commonly occurs because the grid is bound to a data source that exists on a thread other than the UI Thread. When you use multiple threads, you have to be very careful to make sure that you properly marshal the data across the threads. If the grid receives a message from another thread that is not marshalled properly, it will cause all sorts of problems. This is not specific to the grid, it's true of any control.
My guess is that you binding the grid to a data source that is on a different thread and doing something that is causing the data source to raise a notification to the grid and the grid is responding to that notification immediately while it is in the middle of some other process.
The dreaded
DataTable internal index is corrupted: '5'
Has plagued me for a long time.
Setting this propery fixed my issue:
ultraGrid1.SyncWithCurrencyManager = false;
Don't ask me why, it just does.
If you're pulling you hair out trying everything, here's another one worth trying.
skimania said:Setting this propery fixed my issue: ultraGrid1.SyncWithCurrencyManager = false;
Thanks. I tried this, but it didnt have much impact - I have still seen that error once or twice since.
Worse still, it also stopped binding source events firing for the grid. I use those extensively. Took me a while to work out what was wrong.
I think it is just a matter of painfully looking for the real cause of the errors, and getting rid of those.
One MS social blog on this begins in 2006 and continues to the start of 2013. For a pharmaceutical equivalent to the Tsi Tsi fly’s sleeping sickness, read about it at http://social.msdn.microsoft.com/Forums/en-US/adodotnetdataset/thread/18544cd3-1083-45fe-b9e7-bb34482b68dd. Then consider at least one workaround to one scenario in which this is happens.
MS originally blamed this on a threading issue. If it is then it’s their threading issue, not Developers’.
Take a DB101 OrderItem System.Data.DataTableRow that is bound to an Infragistics.Win.UltraWinGrid.UltraGridRow. The user selects a product code or SKU. A Developer would be inclined to handle that selection in a fired event. That’s why events exist.
You would be inclined to handle the SKU selection by also setting the item’s price, qty * price, weight, etc. That’s what OrderItem rows do.
But if the SKU selection is handled in an Infragistics.Win.UltraWinGrid.UltraGrid.AfterCellDeactivate event and values of the other fields in the bound DataRow are set at the DataTable level, you may see, "Unable to update the row: DataTable internal index is corrupted: '5'".
Bloggers suspect the root offender is the MS BindingSource.CurrentItemChanged event. Many have suggested the issue can be caused by a DataTable.DefaultView.Sort or failure to surround DataRow field value assignments with DataRow.BeginEdit() and DataRow.EndEdit(). Even after all DataTable.DefaultView.Sorts were eliminated and, to great travail and angst, all DataRow field value assignments were surrounded with BeginEdit() and EndEdit() (why in the world should we tell a data or any object that we are about to change its property values???!!!) – neither effort affected the corrupted DataTable index error in any way.
The error is avoided if other cells in the bound System.Data.DataRow are not updated inside of the AfterCellDeactivate event. That suggests that updates to other DataRow cells be managed in the Infragistics.Win.UltraWinGrid.UltraGrid.BeforeExitEditMode event alone. But that excludes updates to sibling cells when EditMode is never entered.
In certain situations when validation is handled only by a BeforeExitMode event and not additionally [read: redundantly] handled by an accompanying AfterCellDeactivate event (as described below), an UltraGridCell that is bound to an UltraDropDown and a recipient of an invalid SKU will not enter EditMode despite the approval of every “Allow…” property and precursor event like BeforeCellActivate, BeforeEnterEditMode, etc. It won’t even enter EditMode when the cell is clicked. In fact, for some mysterious [read: Infragistics] reason, the cell isn’t even “Active” anymore! The text value of the cell appears to change as the user types (on this supposedly inactive cell), but it is never really in an EditMode and because of that BeforeExitEditMode is not fired, the sibling fields are not updated and any old bogus SKU value appears to be accepted.
To avoid all of that that, an alternate strategy is:
1) Update sibling cells in BeforeExitEditMode for valid SKU values. Set e.Cancel to true for invalid SKUs.
2) Validate SKU values in AfterCellDeactivate. Don’t update sibling cells. If an invalid SKU was entered, simply return a true value for e.Cancel and the UltraGridCell will return to an EditMode on an actually Active cell.
That seems to negate both issues. Unfortunately it incurs a performance hit because the SKU is validated twice which means at least two index seeks on the Product table.
It seems that the core source of the corrupted DataTable index issue is more rooted in the .NET framework than MS is willing to admit. They say the fix is in CLR 4.5. Unfortunately that may be an excessively costly fix because a move to CLR 4.5 will not work on WinXP OS machines.