Environments
SQL Server 2008 R2
Windows Application in C#
Scenario
I have the desktop application which uses SQL Server. The application deployment builds consist of two scripts #1 Create and #2 Update scripts for deploying the database changes. If creating a new database, it will use #1 script. If updating an existing database, it will use #2 script. There is never a need to run both.
The #2 script – is tied to the Version of the Application Code.
This perfectly fine when the individual user is using a local SQL server.
Problem
We have a client who is using a Central SQL Server where the database is created and individual users connect to same by the desktop application.
Let us say the client is running Application build 02.12.15.140 and the expected database version number is 1.2.45. This week we released to them a new build 02.12.16.310, and in this version, the database version number is now 1.2.51. If a user installs build 140, they will be prompted to update the database with the new #2.sql script, which will change the database version number to 1.2.51. If another user tries to run build 140, they will be unable to connect to the database since application build 140 expects database version 1.2.45 but the database will have been updated to version 1.2.51, due to a central server. Because of this, all users must be on the same client build in order to use the database.
Our challenge is that sometimes to implement new feature or defect, we need to change the database, anywhere from a table design change to a stored procedure change. So new client software versions require an update to the database. We want to make sure that the client software is using the correct database design, so we’ve tied the client software to a database version number. This allows us to ensure that the database design matches what we expect. But it also creates the inconvenience of forcing all users of a database to update the client software at the same time.
Is there is any solution for deploying database changes in such an environment?
Related
I have a disk top application made by c# visual studio. My question is do I have to setup SQL server on each client to use my application? or there is another way to attach my database with my application and compress it as one and send to each client and those just extract that file and use the application correctly?
On a real scenario, your database should be placed on a remote server and the clients should only access the database through your API (that will need to support authentication or any other identity based systems).
If your application only needs to store some local information (relevant only for your client app), then you can just use LocalDB or AppSettings, depending on your data structure.
Otherwise, if your application contains more complex features, then you will need an API and a remote DB managed only by you.
To conclude, you only need to setup Sql Server once, when you want to create the design of it (tables, columns, links). The clients will only have to connect to it and pull their data. And this task can be done without installing SqlServer. This link shows you that you only need System. Data assembly to connect to a Sql Server DB.
Yes you need to instal SQL server on each machine or if you go for LocalDB then also u need to instal SQL server engine ,and you have a better option u need to buy sqlserver from AZURE (it's free for one month try if want click here AZURE)
I know this is kind of a stupid question but it gives me a lot of problems. Me and my partners in college projects have a lot of issues making the database mdf work when we send each other the visual studio projects. It gives us errors about the versions of sql server. Is the only solution to this to install same version of sql servers for the entire team or is there some other workaround?
Yes, you must be using the same version of SQL Server across all PC's.
You can never "go back" in time with a SQL Server database - once a .mdf file has been attached to a given version, it can never be attached to an older version anymore. And you cannot get around this by using the database compatibility level, either - the internal database file structures are just too different between versions, and no backwards "downgrade" path is provided.
One way to get around this would be to have a common, shared server somewhere that everyone can connect to and everyone can work with - making in unnecessary to send around "free-floating" .mdf files altogether... after all, it's SQL Server - a server-based system - not so much a file-based "database" system ....
Another way to go would be to stop sharing the binary .mdf file, but instead work with SQL scripts that you can exchange within your team, and that each team member can execute locally on their respective SQL Server instances - regardless of their local version
I suggest that instead of passing around mdf files, every person on your team creates the DB and then uses SQL scripts to create the objects. These scripts can be very easily created and exported from the SQL Server Management Studio.
This has the added bonus of being able to put the scripts under version control as part of the project.
I made such practice, with one way , by create separate pc running under windows server, only using as sql server to store all data record , then the data is called via "connectionStrings" of IP with server name of user policy, which is also secured by password and username , so this practice is used , to enabled two different programs to share that data , for example , that I made ( one web localhost app to create internal registration ),( the other web app using to access to mainpage via Login form).
I want to build an application that needs a sql database on every machine that uses the application.
Isn't it true that Chrome and Firefox store cookies in a SQL database? I did not remember installing anything like a SQL server while installing Chrome, so my question is: does every user has to install a SQL Server if my app uses one?
The best thing for your purpose is to use database servers, which will be started with your application, like SQLite or Sql Server Compact. That means, you application host the database it self and you have access over ADO.Net. This is a very smart kind of storing local data and very easy.
Do not try to install complex database systems like mssql, sybase or mysql on every client.
For example, SQLite can be delivered with a few assemblies in your product.
This answers gives a nice overview: Lightweight SQL database which doesn't require installation
In order to store information for a client application, you can use SQL Server Compact, or some other solution, like SQLite (with a library to access it).
There are other alternatives, but these two are the most common and stable.
It's true that Firefox stores cookies in a sqlite database. However, that's not the same thing as SQL Server.
If your app needs to communicate with a database, you can a) bundle a sqlite database with it, b) require an existing database on startup (Wordpress does this; you can pass it details for a mysql database to get it to use an existing installation), or c) bundle a full database (like SQL Server Compact) with your application.
I am creating a c# application which requires to use a database and i am also planning to create an installer for my application. I just want to ask which database would be best to use in my application and how do i install it on a user machine while installing my application through installer file.
I have thought of using MYSQL database but for that u need to have MYSQL installed.
Update
i want each user to have there own instance of database when they install the application
You do not have to ship a full database server with your application; only the redistributable runtime which your application would use to connect to the actual database server remotely. In the case of MySQL, you only need the assemblies.
Applications I wrote relied heavily on SQL Server. In order to simplify evaluations and the initial deployment, the installer would install SQL Server Express (installed as an application specific instance). This is an approach I'd recommend if your application is intended to a centralised database.
What is key to understand, especially with commercial application, is that the database engine you install may have to co-exist with existing versions of the respective database engine. That is why application specific instances was created for SQL Server Express.
The alternatives, which are embedded, are:
SQLite.net
SQL Server Compact Edition. The deployment process is well defined.
VistaDB
Embedded databases have some challenges when deployed as part of a server application. For many years, Microsoft refused to allow SQL Server Compact Edition to be used for ASP.NET applications. If the database is per user, per device, an embedded database may be perfect.
Also be aware that MySQL has license restrictions when shipped as part of commercial software (aka you're acting as an OEM, ISV or VAR).
Have a look at SQL Server Express Edition.
It's just a file which you can copy and a class library which allows to access it. And after you finished your installation you can just delete the files (or to keep them if you need them to uninstall the product).
may be u are a fresh.
MYSQL is ok ,but u are creating a C# application,i strongly advise you use mssql
because C# has a close relationship with mssql,develop more convenient.
My advice would be using SQL Azure.
But only if:
You don't need much storage (<1GB).
You don't save sensitive Data there.
Your users have an internet connection.
It's a cloud based Sql Server Database. And the Conneciton is very simple, basically you connect like to any other Database via the Connection String.
www.windowsazure.com
I've built a Compact Framework application to be used by delivery drivers. The system includes a WCF Service and SQL database on the server as well as a SQL CE database and CF application running on the mobile device.
Now the question is how to I update all this easily when I release new versions? The problems are:
it may be deployed to hundreds of PDAs
when first installed on a PDA the SQL CE database has to be populated. This can take a while. I don't want to have to do this each time the app is upgraded so I'm going to have to run scripts to update the db schema rather than just replacing the whole file and repopulating it.
the WCF service code will need to be updated
the SQL database schema will need to be updated
I can see solutions to all this but it seems like a lot of work. I thought it may be helpful to get a few tips before I launch into it all.
Thanks a lot
Mark
I've done some projects with more or less the same requierements.
it may be deployed to hundreds of PDAs
I'll recommend to use an updater, within the application. It checks via a webservice the availability of a new version. Download if theres an update. Then run another process to perform the update(This process I only use to run wceload.exe and then reboot the device).
when first installed on a PDA the SQL CE database has to be populated. This can take a while. I don't want to have to do this each time the app is upgraded so I'm going to have to run scripts to update the db schema rather than just replacing the whole file and repopulating it.
Don't include your database as a file for the application, create the scripts and check if the db exists if not create the db.
the WCF service code will need to be updated
I have an update webservice which is independent so the contract wont change. Which receives the current version, authentication and returns if the update is available and the url for the file to download.
You will need two different address to update and keep the other part working.Just perform a redirect in the new version.
the SQL database schema will need to be updated
I hope you mean that you refer to the server backend so I recommend to use views to search for the information.
If you mean to the SQLCE db you can ship patching scripts or plain erase the db and recreate the db.