I'm using Visual Studio Team System 2008's Database tools to develop my databases. On my local dev machine, when I want to deploy schema changes to the SQL Server instance on my machine, I just use the Data --> Schema Compare feature of VS2008.
But with live databases I can't do this because I can't connect to the database directly from my machine and the server haven't got VS2008 installed.
So I was thinking about the SQLCMD tool. Isn't that what VS2008 uses "under the hood"?
I want to use as part of an automatic deployment strategy. I want to be able to publish SQL scripts generated by VS2008 to the server and have an application run scripts on the live database to update the schema.
UPDATE
I'm trying to achieve automatic change script generation by taking the deploy script VS2008 Database Edition generates and comparing it against a live database. Only I want to do it through code, no tool or anything. It must be able to run from a Windows Service on the server.
SqlCmd would work. If you also want automatic versioning support you should check out Tarantino.Net, a database management tool that keeps track of which sql-files have already been run.
Related
I'm working on an Angular / .Net core project, and I want to deploy it on my homemade server equipped with Windows Server 2016.
I'm stuck at figuring out the best way to create my database from my migrations files. I've seen some topics on stackoverflow about it, but I don't want to make mistakes on my server, so I'm asking for the best way to do that.
The first option I think is to install Visual Studio IDE on my server. Then I can open my project and run an Update-database command, which will read all migrations files and create database.
But I don't think I'm supposed to install Visual Studio on a server...
The second option is something I saw on StackOverflow. In my development environment, I can use the command dotnet ef migrations script, which will generate a script.
But I'm not sure where I should put this script. I think probably in Microsoft SQL Server Management studio, New query and put my script.
Could you please tell me the best way ?
you need dotnet sdk in order to use dotnet ef migrations script but you can use your development pc to connect to your remote SQL Server and do migrations. for this, just point your connection string to remote SQL Server and use either Update-Database or dotnet ef update database
Another solution exists and You can use SQL server Generate Script to query all your database objects and execute it on target SQL server.
The best way you can do "first create" of your database in production environment is to Generate Script from SSMS (SQL Server Management Studio) and run that script on production Db server. The reason of that is because your database is empty (you can put all of data in script) and you can easily change the name, etc.
After that, on new versions of your application, the best way is to use Update-Database -Script and save/add that script to your deployment scripts.
When you are preparing for go-live, try that scripts with ROLLBACK TRANSACTION, if something fails...
I have been using Microsoft SQL Server 2017 for a while (just DDL and DML) and recently decided to install JetBrains DataGrip because I thought it was another DBMS but with dark theme.
When I try to create a new database it tells me to assign a host/user/password/port and I cannot do anything because it can't "connect to the database". I've been using Microsoft SQL Server Management Studio 2017 and never needed to assign a port/password/host or anything? I just created a new database and started adding/filling tables. How does JetBrains DataGrip work?
I noticed that on the JetBrains DataGrip page it doesn't say it's a DBMS, it says it's a "Database IDE". I cannot seem to find information about this on the web.
When considering a RDBMS such as SQL Server, the core component is a service/engine which acts as an interface between the database (files) and end users or applications allowing database functions to be carried out.
SSMS (SQL Server Management Studio) is just one of many possible end users of the SQL Server Database, and happens to have be part of the SQL Server software suite. It should not, however, be confused with the database itself as SQL Server operates perfectly happily without ever seeing SSMS.
Any form of user interface tool for a database needs to know how to connect to the database it is going to manage. In your case you most likely installed the entire software suite with default settings and as such didn't need to know what they were. JetBrains DataGrip however does need these settings.
You can find out what your specific settings are by running the SQL Server Configuration Manager.
JetBrains DataGrip is just a Database IDE to connect to different database engines via only one environment without needing to install management tools for every database that you want to work with.
Ever since I started vb.Net programming, I have been using MS Access as back-end for all my programs.
It is easy to publish application with the MS Access database and run it on another PC without installing the MS Access database.
But now, the project I am working on needs a database with high storage capacity which means MS Access is no longer an option and I have chosen to use SQL Server. Now my question is do I have to install SQL Server on any system that the application will be run on? If so, how will I copy the database that I created on my development machine to other system so that my application will connect to it? Or is there any simpler way of doing this?
SQL Server is a client/server DBMS so you only install the database on the shared server. .NET includes SqlClient, which provides the client components needed for SQL Server applications.
There are a number of options for database deployment. Although you could use restore or attach your development database for the initial database deployment, that won't work well for future upgrades (assuming you want to keep data). Consider using T-SQL scripts and/or SQL Server Data Tools (SSDT). That will allow you to create new databases, such as for development and testing, as well as upgrade existing ones.
Related : Visual Studio 2013 (Professional Edition)
I am trying to create Data Migration Script to deploy the changes on Staging Server.
This works locally fine. But When I try to run the generated Script on Azure Database, I get TextPtr is not supported on Azure platform. I studied more about it & found that the newer editions of SQL Server (sply for Windows Azure (SQL 2014 may be)) has dropped some keywords/functionalities the list can be found here.
The Sql Database Project only provides the Schema Compare, but Data Compare is avilables in tools Section (where we can not set Target Project Type property).
I wonder how can I deploy/Migrate the changes made in one environment to another in such a Situation. Currently I had to overwrite the existing Database on Azure platform.
But this is not Identical also, for first time this could work but not for later, as there could be some changes made to the Staging or other environments.
I had a similar problem, when trying to migrate between a test and staging environment in Azure. As a quick fix, I got around the problem by just doing a "copy" of the dev database via the Azure dashboard.
I am running SQL Server 2012 and VS 2010 with SSDT (SQL Server Data Tools) installed. My dev DB uses stored procs, functions, CLR objects, etc. It has a snapshot of prod data of about 500GB.
I created SQL Server Database Project and then imported the database. This created all tables, views, procs and functions files under schema names. Great stuff -- now I can do a version control just like in other VS projects, create deployments, etc. So far, so good.
But, I am confused as to what my development process should be for changing/adding procs/tables under SQL Server Database Project. It appears that any changes I make are applied to some LocalDb/Projects database and NOT to my dev database.
Am I suppose to author all my objects in that LocalDb, then Build and deploy to my dev database via Publish? I am worried about my existing tables in the dev DB since if the publish process drops and recreates tables, I will loose my prod data snapshot.
What is the right development process to follow in SQL Server Database Project?
Think of the source database (in your case, your database project) as being the "to be" state after deployment. When a deployment is initiated, the executable (SqlPackage.exe) compares the source with the target and generates a difference/delta script to make the target look like the source. This is why we no longer have to specify CREATE or ALTER; the tool figures it out. To answer your question about ongoing development, you can develop either way. You can develop in the project files and publish them to a common Dev database (say, if you're on a team), or you can develop in the database with tools like SQL Server Management Studio (SSMS) and synchronize with the project files with a schema compare (I use the latter technique because I like SSMS).
For deployment, you'll have to have SSDT installed on the machine from which you execute the deployment (SSDT ships with SQL Server 2012 and later; I don't know about SQL Server 2008). You can create scripts to simplify deployment. You'll essentially call SqlPackage.exe (it lives in x:\Program Files (x86)\Microsoft SQL Server\nnn\DAC\bin) with an action and a source. I use Publish Profiles as well to take care of most command properties. So an example deployment might look like this:
SqlPackage.exe /Action:Publish /SourceFile:MyDatabase.dacpac /Profile:MyProfile.publish.xml
For more information:
SQL Server Data Tools Documentation
http://msdn.microsoft.com/en-us/library/hh272686(v=vs.103).aspx
SqlPackage.exe Documentation
http://msdn.microsoft.com/en-us/library/hh550080(v=vs.103).aspx
Make changes inside the VS DB project.
Deploy changes to localDB to test
Publish the database to your production server. I prefer to use Schema Compare to do this manually, but you can also publish the project via the right click --> publish menu (which will also create a publishing profile), or using command line arguments. The publish process won't drop and create tables (unless you tell it to drop & recreate the entire db).
Alternatively, in the project settings you can change the connection string to point to your production server (as pointed out in the comment). However, I recommend against this, as it will then attempt to publish to the production server every time you run a local build (F5).