DataTable internal index is corrupted: '5'

Hello Folks,

Recent upgrade from 10.2.300 to 10.2.700. Everything is in pretty good shape, but I have one small annoying bug with a customization on Inventory Transfer. We utilize the native Lot functionality in Epicor to piece track inventory. I think this is a fairly common approach for industries that store inventory the way we do Off topic; but we are piloting Advanced Unit of Measure in hopes to use this in place of the 20 or so customizations throughout our installation of E10. This is the main reason we updated to 10.2.700.

We have a piece of code in our Inventory Transfer customization that will populate the lot on the ‘To Location’ when a specific Lot is selected in the ‘From Location’. Since the upgrade this event is throwing an error. We can click through and get the transfers to work correctly, but I would like to clean this up if possible.

I have narrowed down the code where the issue is.

The error is:

Application Error

Exception caught in: System.Data

Error Detail

============
##!Message:##! DataTable internal index is corrupted: ‘5’.
##!Program:##! System.Data.dll
##!Method:##! RBInsert

The code that causes this error:

private void view_DataView_ListChanged(object sender, ListChangedEventArgs args)
	{
		// ** Argument Properties and Uses **
		// view_DataView[0]["FieldName"]
		// args.ListChangedType, args.NewIndex, args.OldIndex
		// ListChangedType.ItemAdded, ListChangedType.ItemChanged, ListChangedType.ItemDeleted, ListChangedType.ItemMoved, ListChangedType.Reset
		// Add Event Handler Code

		//MessageBox.Show(args.ListChangedType.ToString());

		if (args.ListChangedType == ListChangedType.ItemChanged)
		{
			if (strLastFromLotNumber != view_DataView[0]["FromLotNumber"].ToString())
			{
				// Set the To Lot Number to be the same as the From Lot Number when it changes
				strLastFromLotNumber = view_DataView[0]["FromLotNumber"].ToString();
				view_DataView[0]["ToLotNumber"] = view_DataView[0]["FromLotNumber"].ToString();
			}
		}


	}

I would start by performing a trace and reviewing the BOs and Methods being called to make sure the generic background code conditions are still the same for the existing code.

Also, perform a sequence of prob messages to determine the root cause of the error.