Just leaving my 2 cents, there is the portable SQL Server mode called LocalDB . You do not need to install the entire SQL Server on the user's machine: only the client adapter and the MDF file that represents the database.

In addition, if by chance you choose the Entity Framework as the framework of abstraction of your database, you can do the data updates using the Migrations . The database is not replaced: it is automatically updated according to the variations produced in your code when developing the application.

When you leave the data on the client, you always have the risk of losing them, there is nothing that can be done. The file can be accidentally deleted by the user or virus, malfunction of the equipment, etc. In fact it is the same risk of the server, the difference is that this one usually has more restriction of access, is not manipulated by lay people (in practice until usually it is :)) and there are good strategies of backup always :)).

What can be done is a strategy of synchronizing the local database with a copy on the server. You can even use SQLite instances on the server to store each vendor's database.

The client will always identify when it has access to the server and initiate synchronization. It will also identify whether the server can be more up-to-date and synchronize in reverse. This can also be useful if the seller uses more than one device.

The server will have a service that will communicate with the client and write the updates to the server copy. Or it will send the updated data to the client when the server is current.

The details of how to do this, strategies for detecting outdatedness would not fit most here. Eventually one can make the file copy all the time, only based on his schedule. It is not the most efficient and robust, but it works in almost every case.

Of course there are always simpler strategies like making more local copies, forcing the user to do something manually, etc.

About the application update

If it is an update, it should not be copied. Simple as that.

And if an overlap happens by accident, only the strategy described above will solve.

If the database structure has changed, there must be a routine that makes the change. %% Of SQLite% is weak. You have to create a new table, copy the existing data in the old table to the new one, treating the differences from the old structure to the new one. Then delete the old one and rename the new one.