Hi,
we are trying to update the datagrid with all the values. this code has been working since many years. for doing an update it is taking almost 20-25 mins. and the application start not responding.
Below is the kind of code, that we are trying to update:
foreach (UltraGridRow gridrow in this.NavigationGrid.DetailsGrid.DisplayLayout.Bands[0].GetRowEnumerator(GridRowType.DataRow)) { if ((string)CustomerGroupCmbox.SelectedValue != SELECT && gridrow.Band.Columns.Exists(Header_customer_group)) { gridrow.Cells[Header_customer_group].Value = CustomerGroupCmbox.SelectedValue; } if (cbShipToContact.Text != SELECT && gridrow.Band.Columns.Exists(NppColumnNames.ShipToContact)) { gridrow.Cells[NppColumnNames.ShipToContact].Value = cbShipToContact.Text; } if (gridrow.Band.Columns.Exists(NppColumnNames.DoNotShipLabel)) { if (Donotshipflagchbx.Checked) gridrow.Cells[NppColumnNames.DoNotShipLabel].Value = "true"; else gridrow.Cells[NppColumnNames.DoNotShipLabel].Value = "false"; }
And while debugging i am getting this exception:
The CLR has been unable to transition from COM context 0x1bdbe0c8 to COM context 0x1bdbe1f0 for 60 seconds. The thread that owns the destination context/apartment is most likely either doing a non pumping wait or processing a very long running operation without pumping Windows messages. This situation generally has a negative performance impact and may even lead to the application becoming non responsive or memory usage accumulating continually over time. To avoid this problem, all single threaded apartment (STA) threads should use pumping wait primitives (such as CoWaitForMultipleHandles) and routinely pump messages during long running operations.
The majority of the time is being spent in msvcr80.dll which is the shared C run-time library (CRT) from Visual Studio 2005 according to Redistribution of the shared C runtime component in Visual C++. Maybe there are issues with the older version of the CRT on a newer operating system.
Are you able to replicate the behavior in a sample that I can debug with?
i am attaching the snapshot. can you let me know, the DLL which is taking time, how to resolve tht?
In your subject you suggested that this started happening only a few days ago. What changed in the application or environments on the day that the behavior changed? This is the best piece of information to help come up with a theory of what might be happening.
Assuming that by debugging the code you are using a debugger to step through the code to see what is happening, there may be better ways to look into the performance issue. I would recommend that you use a performance profiler to profile the application to see what is taking the most time as that will help you know where to look in your code.
Also if any of the code is communicating with an external resource like a database to get data, you may also want to profile the calls to the database.
For the error that you are seeing while debugging, it may or may not be related to the issue that the end users see and it could be something that only happens while debugging. For me to look into this I would need a sample and steps that reproduce this behavior.
Please note that 2008 Volume 2 hasn't been supported since the fall of 2011 and isn't supported on any operating system newer than Windows Vista.
i am still waiting for the answer. Any infragistics expert here, to help me out?
error that i said, was coming up while debugging the code. LIVE users have been complaning, that it is taking a longer time to update, and they need to wait for almost 20-25 mins, to update 180-200 rows!
So, i mentioned the error, to let u know guys, is there any relation with the error and delay for the update?
the dot net framwork is 3.5