I have a LAN composed of 3 PC. Installed in PC1 is the MS SQL database. This computer will act as the server.
The PC2 and PC3 will each have a desktop application that will display the data from PC1.
My problem here is how to make each PC (PC2 and PC3) have the same copy of data.
Suppose in PC2 employee 0001 first name is updated from John to Peter and commit save. Without refreshing the application in PC3, employee 0001 will still have John for the first name.
What would be the best approach for this? My level in programming is not that good, but I'm open to all suggestions/concepts/example/etc..
Thanks.
If you want immediate update on all clients right after data changes then you need some sort of notification system either in a polled or pushed manner.
You can implement push mechanism using for example WCF with callback contract. Your client PCs would need to implement relevant callback interface and be constantly connected to server PC's WCF service. Callback call could actually carry the new data. Each client needs to filter out notifications which resulted from that client's own changes. Push mechanism is quick and efficient way.
Check this stackoverflow answer for example of WCF callback.
Pull mechanism would require a background thread on all client applications checking the server for changes. You can use a separate database table with a version counter that would get incremented each time anything changes on the server. Client applications would poll that counter, compare with latest version they have and update the data when new version is discovered. It is much less effective mechanism though as you need to do the polling frequently and get all the data each time there is a new version. You can make versioning more sophisticated and detect what exactly changed but that can get complicated quickly with multiple clients. Overall it does not scale very well. It is generally simpler than push though and for simple applications with not too much data it would be enough.
You need to tell the other machines when to update. This could be accomplished by simple messages sent over the network using UDP broadcast. Then the other PC could execute its refresh method.
well utivich...this is the same thing as a web application really. it's a common problem. usually the other clients will have stale data until the record is reloaded, or when they save maybe the server will throw an exception on stale data based on sql timestamp. however, with a desktop application you can setup a system with event notification just like a chat application where the server pushes events to subscribers and the clients will be able to update the record or whatever you need to do.
Related
Here is my scenario:
I have to develop a WPF application in C#.NET that has two main users: a Team Lead (TL) and an Operating Technician (OT). This application will be running on multiple separate machines on the same network. The application will be used by the Operating Technician to view a list of Job Numbers and the Team Lead will be able to update the list of Job Numbers as needed.
My problem is that I am not sure how to display those changes to the Operating Technician after the Team Lead has made them.
There will be unique instances of the application running on both the OT's and the the TL's machines.
My first thought was to have the TL's instance update a database and have the OT's instance be periodically checking the database for updates, but this seems clunky and a poor design.
Is there a way that once the TL updates the list of Job Numbers, I can send a "trigger" over the network to the OT's instance to tell it to update?
You could have a TCP listening service on the Operating Technician's machine, and a TCP client on the Team Lead's machine
http://www.codeproject.com/Articles/2418/Making-Socket-Based-Application-Using-TcpListener
You can host WCF service inside your WPF application (like described here for example). That service will run on some port on your OT machine and will listen for incoming events from TL machine (which should know address and port of OT machine). Of course database is still needed to share data, but this database need not to be polled.
Perhaps the easiest solution would be to use some sort of a message bus, e.g. RabbitMQ or ZeroMQ, in a publish/subscribe pattern.
OT's instances will subscribe to a topic, and TL's instance will publish updates with job numbers on it.
why you not use database events to notify the clients about a database update.
https://msdn.microsoft.com/de-de/library/ms189453.aspx
I've decided to try out using MQTT protocol to offer a pub/sub service for the different applications. This will solve a few things with the problem as there are actually multiple Team Leads who will each have their own Operating Technician.
Now to find out how to implement MQTT with .NET.
Anyone?
I have a Windows service that currently outputs logging activity to either a text file or a database (depending on the activity). What I would like to do is to have a way to run another process (probably an executable) that can connect to that service and receive activity updates from that Windows service using like a publish/subcribe approach.
In theory, I guess this can be done by hosting a socket connection on the Windows service and pushing activity data as it happens. I wonder though if there is s better approach? Is there maybe a framework that can do all this for me easily? Or maybe I should use a MQ product to broadcast the application activity?
I am using C# .net version 4.5
There are several ways:
Socket is very good two-way communication
WCF is also another option, also two way communication support
Database - if you need to keep the history of the signals, you probably use one table where server/host inserts into a table and client reads from table using SQL Dependency. You can read new signals without timer or waiting, almost in real time.
Another good option is SignalR.
I have been using all technologies except WCF.
I am building a social application and was wondering how facebook achieve their notifications.
As you know, facebooks notifications are instant. As soon as someone takes an action, people are notified.
I assume they don't have a query running on the database all the time.
Can someone point me in the right direction. Thanks
Since your question is tagged with C#, ASP.NET you should use the awesome SignalR library. Basically SignalR enables you to send push notifications to the clients. Which exact underlying technique it uses is influenced by the capabilities of the Server and the Client.
There is a big real time chat site called jabbR that is built on top of SignalR:
http://jabbr.net/
Here are some more links that should get you started.
Project site: http://signalr.net/
Hosted Code (Open Source): https://github.com/SignalR/SignalR
Wiki: https://github.com/SignalR/SignalR/wiki
Projects using it: https://github.com/SignalR/SignalR/wiki/Projects-Using-SignalR
Facebook uses a messaging protocol (which it designed) called Thrift. This allows notifications from clients to servers with very low latency. I would imagine updates on the server would be triggered depending on the user action and relevant users that are logged in would be notified by the same mechanism.
Using a messaging protocol such as thrift (also see Protocol buffers) clients don't have to poll the server for updates, instead the server can push notifications to clients. To do this the server needs to have a notion of who is logged in at any one time (Login, logout handshaking) and of them, who should receive notifications from a particular client action.
Easier said than done, especially when you have 800 million potential users logged in!
You might want to take a look at http://nodejs.org/ - it is an event-driven model which is perfectly ideal for a 'social network' / instant notifications scenario.
FYI: You also might find that using a non-SQL database such as MongoDB (http://www.mongodb.org/) will be a lot faster when querying from the DB since each 'person' object in a social network scenario has his/her own unique attributes - which in a normal SQL database is hard to design.
I'm developing an application and need to send some real-time updates to users logged in. I'm currently developing for an XRM system which only offers email notifications, so to get things up and running a bit quicker I'm going to resort to polling the database.
I want to start a new process in the Application_Start() method in global.asax that will poll the database and broadcast among clients. The problem is I'm a bit of a noob and don't know what I need to get started.
I've read http://haacked.com/archive/2011/10/16/the-dangers-of-implementing-recurring-background-tasks-in-asp-net.aspx and am aware of the potential flaws, as I said it's nothing more that getting it running first.
Could anyone tell me what kind of project I need to add to my solution? I was also thinking that it might work out a bit better if it runs async allowing me to poll different entities for updates simultaneously.
The polling is going to be regulated by the server, clients don't request for the poll so no long-polling with the database, the updates get pushed to the users subscribed to a groups. This will help me keep the polling minimal and also turn the polling off if no one is logged in.
I am looking for a way to detect if a SQL Server fails to respond (timeout/exceptions etc) so that if our C#/.net program trying to access the server asks a server that is down for maintenance, it will jump and try another automatically.
I would like a solution where we do the SQL connection and THEN get the timeout. We could build a WCF service and ask that one, but that is a bit of an overkill in my opinion.
The sync between multiple server locations is not the issue here.
Our development platform at the moment is SQL2008express as its plenty at the moment, but later on we might switch to real SQL2008 servers (or whatever is latest when the time comes).
Clients will connect to "first known" in a "last known dynamic list" asking a "rootserver" or hardcoded configs for first lookup.
When clients loses connections, they will automatically have to try to reconnect to other nodes in the clusters and use whatever returns a reply first. The nodes will individualle connect and share data through other services which we also distribute in the cloud.
We know that mirroring and clustering might be available through large licenses, but our setup demands a more dynamically "linking" and we believe this approach suits our needs better.
So... to be specific:
we need to detect when a SQL-server goes offline, when its not available anymore. Eg. in the middle of a transaction or when we try to connect.
Is the best approach to do a "try-catch" exception handling or is there better tricks when looking over WAN's and using C#/.net =
EDIT
I've received a lot of good ideas to use failover servers, but I would like a more programatical approach, so whats the best way to query the server if its available?
Situation:
4 different SQL servers running on seperate WAN/IP's, each will maintain a list of "where the others are" (peer-to-peer). They will automatically be moving data from each other (much like a RAID-setup where data is spread out on multiple drives)
A client retries the list from an entry-point-server and asks the first available.
If the client asks a server that is "down for maintance" or the data has moved to one of the other servers, it must automatically ask the next in the list.
What we are looking for..
is the best way from within C#/.net to detect that the server is currently unavailble.
We could have a service we connect to and when we loose this, the server is off
We could make a "dbConnectionSqlServer3.open()" and wait for the time out.
We could invest in "real cluster servers", and pay a lot + bind ourselfs to 1 SQL-server type (The SQL platform might change in future, so this is not a real option)
So whats your vote here: 1 or 2?
or can you come up with a number 4 that beats the h**k out of ideas? :o)
I would probably take a different approach.
I'd designate a server (with a failover partner) to be the holder of the server list. It should monitor all of the other servers for availability.
When the client initially wants to connect, it should contact the list server and ask it what to use. From that point forward the client should stick with it, unless a failure is detected. At which point it should contact the list server to get a new one.
The list server would be able to implement any type of load balancing you wanted just by telling the clients which one to connect to. Further, deploying new servers would be easy as the only "list" would be maintained by this primary server.
This completely ignores any sort of server synchronization issues you might have.
One major benefit is that by having a central server doing the monitoring your clients won't have to fall through 3, 5, or 10 servers just to find one that's up. which would increase responsiveness.
UPDATE
#BerggreenDK: The best, and probably only assured way, to detect if a server has failed is to connect to it and run a simple query. All other mechanisms such as pinging, a simple check if the port is open, etc. might give a false positive. Even having a process running on that server itself may give a false reading if the server itself is up but SQL Server is down (e.g: the database is offline).
Ultimately it sounds like your client will have to connect to one of the gateway servers and get a short list of sql servers to attempt to connect to. On failure, it will have to rotate through that short list. If all are down it will have to go back to the gateway and ask for a new list to start the process over.
In the ConnectionString you can specify a failover partner like
Data Source=<MySQLServer>;Failover Partner=<MyAlternateSQLServer>;Initial Catalog=<MyDB>;Integrated Security=True
On http://www.connectionstrings.com there is a section talking of DataBase mirroring.