|
-
Aug 10th, 2011, 07:00 PM
#1
Thread Starter
Hyperactive Member
Realtime Database Queue [SQL]
Hello all,
A recent project of mine requires a real-time view of a data queue so the user can see, with a lag of preferably no more than 3 seconds, what all the users connected to the SQL Server database are doing.
What I'm wondering is, is the TableAdapter.Fill command at all suited to that? Could I get away with calling .Fill() every 3 seconds, or would that result in a rediculous amount of network traffic? There are 3 tables I'd need to Fill, with (on average) 7 fields per table, and (again, on average) 30-40 records in each table.
Alternatively, would I be better off setting up a flag mechanism of some description? ie. all the clients continually check for the flag and only call .Fill() when it spots it. Would it be better to continually call .Fill() on a 1record-1field table, looking for it to change to true? Or even continually use File.Exists() to look for a flag file on the network?
How would you solve this problem?
Thanks,
Qu
"Why do all my attempts at science end with me getting punched by batman?" xkcd.
| Pong| |
Sorry for not posting more often.
-
Aug 11th, 2011, 08:12 AM
#2
Re: Realtime Database Queue [SQL]
I don't know enough about the TableAdapter to know whether that is the best method, but combining it (or an alternative) with the Flag idea is a good one - because it does reduce the workload significantly when there is nothing new to display, which could well be be quite often.
Note that as there are multiple users running this, a simple "true"/"false" wont really be apt, because it may not apply to all of the users (who will probably be refreshing at different times). What I would recommend is a date/time of the last update, and each user instance keeps track of the last value it displayed the data for (if the table has a newer value, run the full refresh).
-
Aug 11th, 2011, 04:21 PM
#3
Thread Starter
Hyperactive Member
Re: Realtime Database Queue [SQL]
The date-time idea is a good one: I was going to set up a boolean for each connected user within the "Users" table of the database, but date-time is so much more elegant.
Any idea if a 1x1 table is the right way to go, or if there's some better mechanism I could use to throw out the flag?
"Why do all my attempts at science end with me getting punched by batman?" xkcd.
| Pong| |
Sorry for not posting more often.
-
Aug 11th, 2011, 04:29 PM
#4
Re: Realtime Database Queue [SQL]
The 1x1 table is what I would go for.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|