C#/SQL Cloud application - clients on different versions -

I am preparing a small application for a group of users at different physical locations. This application will connect to a central database in the cloud (well, on a central server - Cloud looks, but not really cloud). The database is centered to facilitate backup in a central location. I am an experienced developer, and connection methods, codes and other factors are not really a problem.

However, I need to allow the user to upgrade to the new version when the user is fit - not on any kind of program. In a new update, the database schema may possibly change. So I'm going to participate in the problem of downloading a new version of the user and renewing the database. Then user B, C and D will get errors when they try to hit the database because there can not be tables / views

I have about maintaining different databases on the same server Thought is there. When a user upgrades, we will "push" our database values ​​from DB_V1 to DB_V2 and they will use that one. User B, C & amp; D will still be able to use DB_V1 until the decision to upgrade. After all, when all users upgrade from that database, then DB_V1 can be removed.

Can I get some ideas on the best way to handle it in the Cloud-Esc apocity? The client can be on different versions, how is DB updated normally / how is it handled? Unfortunately, it is tough and there is no silver bullet.

Unfortunately, it is difficult and there is no silver bullet. The name of the game is version, and you need to support overlapping editions. You must have a version of the Access API. for example. Consider the client that there is a comfortable interface with a "cloud". The root URL for the API may be some code like http://example.com/api/v1.1/ . When you deploy a new version, you take the API to http://example.com/api/v1.2/ and expose the new features in this new API, But the old V1.1 also gives grace to clients for upgrading to v1.2, and after retirement of sufficient number of customers, v1.1 retire for some time in the future. There is a good resource on the subject.

Now the real problem is behind you, which is behind the code URL service, to maintain backward compatibility with the previous version, you have to carefully design each upgrade step. Is it very likely that both overlapping versions will use the same storage (same DB) if a user connects an item using the v1.2 API, then it is expected to use the v1.1 API later, Although possibly v1.2 some features are remembered. At the end of your back, you have to decide how to control v1.2 properties for added / edited items using v1.1 API (like default values, NULLs etc.). As I said, it is difficult and there is no silver bullet. Sometimes you are also cutting a bullet and can not provide any layer compat (v1.2) items v1.1 APIs are not visible to customers, i.e. separate storage, different dibies Use the).

When your customer uses DB directly? To wit. There is no clear API, the customer connects directly to the database. The chances of your success are greatly reduced ... you can communicate with the DB, use the API, like Use only stored procedures for everything as a schema namespace, you can provide a version such as. exec [v1.1]. [GetProducts] versus exec [v1.2]. [GetProducts] . But cumbersome, harsh, error prone, and you can kiss God Dev wizard, Orms and other whistle and goodbye of the hours.