Real Time DataTable Updates

Question

I do real time machine control.  I have a string NewSN_Number that is updated by the machine 5 times per second.  I want to tuck it away safely in a Data Table.  When the machine stops I push the datatable to an XML file.  The following 3 lines are shutting the program down.

            SelectedRow.BeginEdit();
            SelectedRow[ColumnNumber_Last_SN] = NewSN_Number;
            SelectedRow.AcceptChanges();

When the program crashes there are no warning messages or logs anywhere that I can find.  It just closes.  That is one of the things that bothers me the most.

The work around is to only update the datatable right before it is saved.  Still, I would like to know what is going on and if there is a faster way.

Answer 1

Yes that I had also last week when the temperature of my processor became to high, a vacuum cleaner can than often help.

Not very much to do with ADO Net but maybe does it help.

---

Success
Cor

Answer 2

Hi,

i would at least end the edit session before accepting the changes:

SelectedRow.BeginEdit();
SelectedRow[ColumnNumber_Last_SN] = NewSN_Number;
SelectedRow.EndEdit();
SelectedRow.AcceptChanges();

also do you have 'break on ALL errors checked in VS? (debug/exceptions clr exceptions: thrown + user-unhandled)

---

Regards, Nico

Answer 3

According to the online help, AcceptChanges automaticly executes EndEdit first if edits are pending.  I tried it and it made little difference.

Yes, break on all errors is checked or at least under Debugging almost everything is checked.  "Break on all Errors is really a VB thing a this is in C#.  I even tired to catch and expetion in these statements and never got one.

It is the total lack of a postmortom that really bothers me.  Kind of like WPF binding but you get used to that.

Answer 4

According to the online help, AcceptChanges automaticly executes EndEdit first if edits are pending.  I tried it and it made little difference.

Yes, break on all errors is checked or at least under Debugging almost everything is checked.  "Break on all Errors is really a VB thing a this is in C#.  I even tired to catch and expetion in these statements and never got one.

It is the total lack of a postmortom that really bothers me.  Kind of like WPF binding but you get used to that.

Are you using threading? backgroundworker, ... because these kind of weird errors are typical for cross thread errors.

Furthermore, is it a typed dataset, how do you get the selectedrow, ... ?

---

Regards, Nico

Answer 5

Nico,

I'm curious, how do you think that a computer without a running processor because of a crash can push something in a database?

---

Success
Cor

Answer 6

I even tired to catch and expetion in these statements and never got one.

That bothers me ... if the try/catch is never catching an exception, then your problem is not happening there. What did your try/catch look like and what did you do in the catch to log the error? Nico had a good point also about threading being a possible problem ...

How about posting a little more of the relevant code?

---

~~Bonnie Berent DeWitt [C# MVP]

geek-goddess-bonnie.blogspot.com

Answer 7

I comment these three lines out and it works fine. I uncomment them and it crashes.  It has to be in these three lines.

These lines are called from a routine that responds to an event / message from TcpClient.  Since it is WPF I assume this is a thread controlled by the dispatcher and not a helper or background thread.  Everything before it is analysing the string and extracting a number.  I can keep store this number in an array but not in the datatable.  The crash is not immediate but takes 10 to 20 seconds.  I have seen other questions about ADO speed problems. I have often wondered if it was somehow overloading the dispatcher.  This theory is based on too many assumptions to be correct.

Cor Ligthert, I do not understand your question.  For this prolem I am just pushing it to a datatable.  I only push the datatable to an XML file when the machine is idle and I am not getting all the rapid updates.

Answer 8

These lines are called from a routine that responds to an event / message from TcpClient.

This indicates to me that you probably ought to use locking, I bet the rapid updates are stepping on each other in separate threads. Try something like this:

// declarations
private object LockObj = new object()
// lock it before you access it
lock (LockObj)
{
    SelectedRow.BeginEdit();
    SelectedRow[ColumnNumber_Last_SN] = NewSN_Number;
    SelectedRow.AcceptChanges();
}

The above lock should also include the code that gets the SelectedRow, assuming that at different times the SelectedRow might be a different Row.

---

~~Bonnie Berent DeWitt [C# MVP]

geek-goddess-bonnie.blogspot.com

Answer 9

These lines are called from a routine that responds to an event / message from TcpClient.  Since it is WPF I assume this is a thread controlled by the dispatcher and not a helper or background thread.  

Then your problem IS a threading problem. Your assumption that the thread is safe is false. I doubt that Bonnie's idea of locking would help; you need to marshal the code to the ui thread, using begininvoke or invoke; look here: http://msdn.microsoft.com/en-us/library/ms171728.aspx

---

Regards, Nico

Answer 10

My real assumption is that the lines would take less than 200 msec to execute (even with all the interruptions of the dispatcher).  If it is a threading problem then it is because data table operations are too slow.  Not sure why.  The I7 CPU is running at half clock speed one core is at 5% and the other at 15% and the other 2 basically asleep.  The .NET for them must be really inefficient or overly complicated.  They could have a lot of internal timers to slow the down but I am not sure why they would.

I will accept the answer that it is a threading problem.  The problem I do not mind as much as never getting any diagnostics or being able to catch the event.

Such are the mysteries of life that will never be solved.  Thanks all for the feedback.

Answer 11

If it is a threading problem then it is because data table operations are too slow.  

It's not the speed that matters at all ... it's the fact that two (or more) different threads may be trying to access the same object at the same time. As soon as you get multiple threads involved in anything, there's no way to predict when any given thread will try to access something. That's why you've got to be aware of thread-safe methodology.

I don't know why Nico doesn't think my locking suggestion will help and I believe his suggestion only applies if it's affecting UI controls ... but, in any case ... have you tried either suggestion? 

---

~~Bonnie Berent DeWitt [C# MVP]

geek-goddess-bonnie.blogspot.com

Answer 12

I don't know why Nico doesn't think my locking suggestion will help and I believe his suggestion only applies if it's affecting UI controls ... but, in any case ... have you tried either suggestion? 

---

~~Bonnie Berent DeWitt [C# MVP]

geek-goddess-bonnie.blogspot.com

@Bonnie

Hi Bonnie, the reason that i think it won't work is indeed because i think UI controls are affected: 

datatables are most of the time bound to the ui, so any changes to a datarow triggers a bunch of events that eventually end up updating the ui; if the original data-changing thread is not the ui thread, and there is no explicit marshalling, all those other events also happen on the non-ui thread! 

@Michael

there's a thourough explanation here how and why to marshal threads: http://msdn.microsoft.com/en-us/library/ms951089.aspx

---

Regards, Nico

Answer 13

Michael,

I replied on this one

When the program crashes there are no warning messages or logs anywhere that I can find.  It just closes. 

At the moment the program crashes nothing can be done. 

A normal procedure to track this is using a trace log  

A sample I found on Internet, I know nothing about it.

http://www.daveoncsharp.com/2009/09/create-a-logger-using-the-trace-listener-in-csharp/

---

Success
Cor