Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have a requirement as below.
Windows application in c# with My sql database.
MySql database in both local and server .
One centralized server with many client
Synchronizing the server database at each time when the new entry or update is
happen in local machine.
The server data also needs to be updated in local at regular intervals inorder to avoid conflicts
I need to know what is the best approach to follow to make this synchronization without any conflicts.
Thanks in advance
If your "local machines" are always connected to the server, you don't need a local database - you can connect directly to the server as one MySQL server can handle multiple clients...
If, however, your central server is not always available or your clients can go offline and should still be able to work and they synchronize data when they come back online, then what you need to build is an Occasionally Connected Application.
See if you can use any of the recommendations on that page. If I were you, I would start exploring Synchronization Services for ADO.NET (MySQL has a full ADO.NET provider)
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 2 years ago.
Improve this question
I'm working on a small WPF Project. The data is being stored on Server machine. I want, that the clients can access that database by a WPF Software. The connection is only LAN. Any idea, how to develop my WPF APP further? Perhaps WCF? any book or any quelle that can help me specific with this topic?
thanks guys!
It depends on how your application will be used.
From a WPF application you can connect directly to your database and it is the easiest way but, not allways the best.
If your application will be used only on internal network, you can use SQL Connection, an ORM like Entity Framework etc.
But, if you want to use your application externally, I mean for exemple at home, you will need to open the TCP/IP Port on your Database Server in order to be able to connect from your application using SQLConnection. This is not difficult but will make your server vulnerable against hacker attacks. In this case, you can use a web service to publish on your server and consume it in order to communicate with your db. The disadvantage of this is the development time. Ofcourse developing a web service and consuming it will take more time to develop than connecting directly via an SQLConnection.
For me, you must choose the most optimised for your case.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I am new at programming and I want to make an app which uses a SQL Server database. Most important feature of this database must be usable for every computer which has the app installed.
I mean, when I give this app's setup file to another person, this person should be install my app without installing SQL Server program, extra things etc. I don't know it is possible.
I created a database with "SQL Server Object Explorer" inside of "(localdb)\MSSQLLocalDB" but when I tried to add new connection, server name was empty. So I didn't import a database to my project.
So how/where can I create and import a database ?
If you want a local SQL database with your application, that is: data is not shared between devices or users, you'll want something like SQLite which is designed for embedding in distributed applications.
To use it you need to link against the binary and include the binary in your application package. Or, you can use the SQLite team's native C# SQLite library. See here: https://system.data.sqlite.org/index.html/doc/trunk/www/index.wiki
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I am looking to change the current architecture of distributed winforms application developed using TCP messages and the client talks to database directly. I know this a bad design and I am entrusted to change this. I have been recruited for the same.
Bit of Overview:
Client uses Winforms applications
Client loads the initial data from database directly
Clients listens to the Server (Winforms application with TCP listener)
If an update is made in an any of the entity, client will update the database directly and sends the message to server, which in turn send the information to other clients. Then these clients would refresh the data from database
Technologies Used: VB.NET, Entity framework, Oracle Database and TCP Listener.
I need all your advise about what would be best solution/architecture for the same. I thinking about using WCF with duplex communications for messages.
Thank you in advance for your replies.
Use a simple WinForms (or WPF if you can) client, WCF server, EntityFramework for ORM and Oracle for DB.
The client calls the server. the server uses EF to call the DB. This 3 tier design is pretty common and basic. What's wrong with it?
PS: I would recommend against using duplex communication because it's over complicated and doesn't always work. What is your specific need for it?
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I have an old Access database (.mdb/2003) that was used as application for the sales representatives team.
Problem:
My task is now to write a WinForms application that every sales representative will in future have on his laptop. All data that each of them are collecting must then be updated afterwards to a central db in the company. The Access database must be migrated to SQL Server.
I was first thinking of a web application, but this option is not allowed or otherwise possible.
Is there a way that each sales representative stores his data on a local db on his laptop, and then sends his db via E-Mail, In the end the data of all sales representatives must be merged together into the central database. Any idea, that follows this concept -> store data locally and send it via E-Mail, to fill the central database?
Regards and thank you for any help in advance!
it's not such a big deal to write a c# application to store data in xml format, maybe zip and encrypt it, attach it to an email and then send it to a specific address (for example using .net SmptClient class).
the bigger task will be to write a service on server side to wait for incoming emails and write attached data to sql server ...
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
I have been using SQL Server 2008 as the database for an windows desktop application. I am re-engineering the product and I might use SQL Server 2008 or MySQL going forward.
So I am thinking of a general solution for archiving. Is there something similar to SqlDump in SQL Server 2008? Presently I am not using an ORM, I might plan to use Entity Framework in the coming days.
Basically I want to remove the old entries and whenever report has to be generated, I have to recover it as well..
Also I have an issue here: what if the database schema changes? How do we restore the old database?
If there is no common solution i would appreciate the solution specific to SQL Server 2008.
The topic of archiving, in general, is too broad for this forum. But I'm going to put in my two cents. I have found that it is best to archive records (i.e. literally move records from one table to another) and oftentimes in a different database.
This handles the schema issue because you can modify the schema of the archive table and keep it in sync.
It also allows you to write specialized reports that actually include archived data as an option.
It further allows you the ability to setup the server architecture for your archive databases differently than your production databases. They don't even have to be on the same server. They don't even have to be linked. Building a .NET application to move rows from one database to another on regular intervals based on your needs would be pretty trivial.