Delhi Chapter Meeting on Replication and Client Interaction

1. Replication scenarios.
2. Types of replication.
3. Updating data at Subscribers.

1. Server to server Scenarios
   
   • Improving scalability and availability
   • Data warehousing and reporting
   • Integrating data from multiple sites
   • Offloading batch processing
2. Server and Client Scenarios
   
   • Exchanging data with mobile users
   • Consumer point of sale (POS) applications
   • Integrating data from multiple sites

• Data changes infrequently.
• It is acceptable to have copies of data that are out of date with respect to the Publisher for a period of time.

• The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber.
• The application requires access to intermediate data states. For example - firing a trigger
• The Publisher has a very high volume of insert, update, and delete activity.
• Subscribers to transactional publication should be treated as read-only

• Multiple Subscribers might update the same data at various times and propagate those changes to the Publisher and to other Subscribers.
• Subscribers need to receive data, make changes offline, and later synchronize changes with the Publisher and other Subscribers.
• Each Subscriber requires a different partition of data.

• There are a small number of Subscribers.
• Replicated data is mostly read-only at the Subscriber.
• Subscriber, Distributor, and Publisher are connected most of the time (for immediate updating subscriptions).

• Ask as many questions as possible, no matter how silly they sound.
• Know the "Existing System" before adding new feature or changing it.
• Keep your requirements organized. This will not only help in future references but also help you organize stuff.
• Break the requirements to smaller standalone tasks.
• Prioritize the tasks, and Involve client in this process. Identify tasks that are dependable on others to complete first. Priority is sometimes client driven and sometime driven by complexities of implementation or both.
• Be adaptable to requirement changes in later stages also.
• Identify changes for current release or put them for next release. If changes are not of high priority then mark them for next release else incorporate in current release.
• Take approval if time exceeds your expectations from what is initially anticipated for changes that client requests or you oversee.
• Don't surprise the client. Keep him in loop as much as you can take his approval before working on a feature.
• It's sometimes said that it's easier to ask for forgiveness than it is to seek permission.

• Give reasonable estimates at the first place.
• Inform client "when estimates exceed", tell then the reason why it is exceeding and take approval. Sometimes complications occur during development and more time is needed then please inform client ASAP.
• Stick to the time you committed.
• Do NOT wait until you have met or exceeded an estimate before you notify the client that the project is running late.
• Never keep the client in the dark when you exceed your estimates as it will only arouse suspicion and mistrust when the project deadline whooshes past!
• Release Plans are required to be formally approved before work commences. Similarly, any changes to the release plan need approval. Changes to the release plan can take following form:

• Who Are Your Customers?
• Also Identify customers as Technical or Non-technical. Put yourself in their shoes and think as you were them and draft your communication accordingly.
• Every Customer is Your Favorite Customer
  Treat each customer as if he or she is your favorite customer. Put enthusiasm in your voice when Favorite Customer calls you for the 10th time in a week asking where his document or her training device is. It's tough to be cheerful all the time, but put your best attitude out there. Nobody wants to deal with a cranky, grouchy, bad-asp attitude.
• Be Polite.
• There is nothing called more communication. Clear all your doubts and accept things only when they are clear to you. This may sometimes be like bugging the client, but in long run it always helps.

Praveen Kumar(Admin/Editor), Kamal Rawat, Dinesh Beniwal(Editor), Manish Dwivedi, Gaurav Sharma, Pradeep Pandey, Purushottam Rathore, Deepak Verma(all C# Corner Team), Arjun Panwar, Manish Singh, Deepak Dwij, Vikas Mishra, Manoj Panwar, Amit Maheswari, Rajesh, Vineet Saini, Akshay Tewatia, Virendra Kumar Patel, and Rakesh Kumar.