Optimising data retrieval in application with high refresh rate
-
Hello, I am developing an all which requires me to update the screen rather often. At the moment it is set to 1 second, I can change it, but i wouldn't want to move it much past 5 seconds. At the moment I have a BackgroundWorker doing the TableAdapter.Fill(), and then I am clearing the DataSet and Merging it for the final outcome. However, this is slow enough to block the UI, making things very jerky. I tried moving the clear and Merge to the background thread, however when I did that it throws errors when you try to interact with the DataGridView whilst it's updating. Any ideas? Thanks, Brendan
-
Hello, I am developing an all which requires me to update the screen rather often. At the moment it is set to 1 second, I can change it, but i wouldn't want to move it much past 5 seconds. At the moment I have a BackgroundWorker doing the TableAdapter.Fill(), and then I am clearing the DataSet and Merging it for the final outcome. However, this is slow enough to block the UI, making things very jerky. I tried moving the clear and Merge to the background thread, however when I did that it throws errors when you try to interact with the DataGridView whilst it's updating. Any ideas? Thanks, Brendan
Not possible to have a real time app polling a database, sorry :). Rethink your design. I don't even know what your app does, but I'm guessing its not changing the entire table every second. Rethink your approach. You will likely need to write an IOCP based UDP server to be able to keep up with real time updates on multiple clients and stop sending entire tables to the client. Its not necessary. You just need to send new data.
-
Not possible to have a real time app polling a database, sorry :). Rethink your design. I don't even know what your app does, but I'm guessing its not changing the entire table every second. Rethink your approach. You will likely need to write an IOCP based UDP server to be able to keep up with real time updates on multiple clients and stop sending entire tables to the client. Its not necessary. You just need to send new data.
Basically my app is a monitoring application for status codes on alarms. The reason I need fast refreshes is that the application needs to see when the other operators do things - i.e. acknowledge a status code, etc. Ahh, bugger. I was hoping the apps could talk directly to the SQL server itself. I'll look into your suggestion though! Thanks!
-
Basically my app is a monitoring application for status codes on alarms. The reason I need fast refreshes is that the application needs to see when the other operators do things - i.e. acknowledge a status code, etc. Ahh, bugger. I was hoping the apps could talk directly to the SQL server itself. I'll look into your suggestion though! Thanks!
I think there is such a thing as wiring up events between sql server and c#. I have never pursued this info as I find the concept horrifying!
Never underestimate the power of human stupidity RAH
-
Basically my app is a monitoring application for status codes on alarms. The reason I need fast refreshes is that the application needs to see when the other operators do things - i.e. acknowledge a status code, etc. Ahh, bugger. I was hoping the apps could talk directly to the SQL server itself. I'll look into your suggestion though! Thanks!
Gotcha. Yeah, I don't think polling the database server constantly is going to work very well with multiple clients :). Since you probably don't want missed updates, I'd probably go with TCP/IP vs. UDP. Although UDP wouldn't necessarily be a bad thing here. TCP/IP is probably going to be easier to implement a reliable system with though. Your design would probably be that everybody connects to the TCP/IP IOCP server through a simple text or binary protocol you invent. When somebody updates something, you push the update out to all the clients. The TCP/IP server would be the only process writing stuff to the database in the background.
-
I think there is such a thing as wiring up events between sql server and c#. I have never pursued this info as I find the concept horrifying!
Never underestimate the power of human stupidity RAH
Yes, SQL is able to call code or COM objects, etc. It is NOT intended to be used as a push mechanism to multiple clients. Thats even stated in the docs. Its intended to be used as a notification mechanism for a single server process. More efficient then hitting up the database every second, but he's still going to need a server piece in which case he might as well "do it right" :).
-
Yes, SQL is able to call code or COM objects, etc. It is NOT intended to be used as a push mechanism to multiple clients. Thats even stated in the docs. Its intended to be used as a notification mechanism for a single server process. More efficient then hitting up the database every second, but he's still going to need a server piece in which case he might as well "do it right" :).
I have never actually read the docs, not something I would recommend to anyone, live updates of data changes from the server yech! If you were running WCF could that act as the choke point monitoring all changes rather than the TCIP suggestion you put forward?
Never underestimate the power of human stupidity RAH
-
I have never actually read the docs, not something I would recommend to anyone, live updates of data changes from the server yech! If you were running WCF could that act as the choke point monitoring all changes rather than the TCIP suggestion you put forward?
Never underestimate the power of human stupidity RAH
Nah, WCF sucks. I will never use it again. It is easy to implement though. We have a couple of WCF components in my current project (not my idea!). WCF is slow (too much XML traffic) and has no push mechanism. I don't think WCF would scale too well either. The only thing that scales into 10's of thousands of connections per server is going to be TCP/IP (or UDP) using IOCPs. Not sure if the OP has to go that far though :).