How do I allow an SSIS package to consume a Visual Studio 2005 or 2008 Database project which houses the creation scripts for the tables and other objects (note: this is not Visual Studio Database Edition - just Pro with Business Intelligence)?
The idea is to use this to recreate my test instance by building the schema from source safe and the data from prod.
I have access to both VS2005 and 2008 Pro and this is hitting Sql Server 2005 for both Prod and Test.
The short answer is, you cannot "allow an ssis package to consume a VS 2005 or 2008 db project". I am not sure why you want to use SSIS to run the create scripts. You can run the scripts from sqlcmd utility.
If you still want to use SSIS, this is what I would do:
create a deployment script (VS for DB Pro can do that)
create a package
in your control flow, use Execute Process Task and configure it to run sqlcmd with the script file as your input
You can call the scripts in the DB project through Execute SQL tasks in the SSIS package. However, there's not a direct way to consume them.
Related
I need to automate SQL Server DB deployment using Azure DevOps. I don't want to give any alter statement. I will have a folder structure with tables, stored procedures, views & functions in repository. Every folder will contain only create scripts. Is there anyway to create DacPac file with that folder structure or any other way, other than DacPac deployment using that folder structure?
Note: I don't want to create DB project using Visual Studio. And I don't want to create a DacPac file directly from SQL Server Management Studio and checkin the same to source control. And I am not in a situation to pay for license.
You can try to use SQL Database Projects extension in Azure Data Sudio. It supports VS SQL Database Project and it supports builds from the command line: Build a database project from command line
What you describe is the database project. A dacpac is the build output of a Database project. There are no licenses involved. All the tools that produce dacpac files are free:
Both SQL Server Data Tools (SSDT) and SQL Server Management Studio (SSMS) are free, standalone downloads.
You can install SSDT on top of Visual Studio Community which is also free.
Azure Data Studio supports database projects. Also free, open source and works on Mac and Linux. I'm using it on Mac to edit database projects, using a SQL Server Developer Edition in a Docker container.
The sqlpackage command-line tool can extract a dacpac from an existing database, publish it or generate a migration script. Also free and a standalone download
Microsoft SQL Server 2016. I've done an export of a table (using the wizard) I saved the package and I see it in the msdb.sysssispackages table. But it doesn't show up in the Integration Services Catalogue section. So how can I make it show up so I can execute this package again?
If you're executing it through SQL Agent, the Package Source is SQL Server for packages stored in the msdb
A confusing bit of terminology that I started to respond with on your deleted question is that you can store a package in SQL Server and that usually means the msdb.dbo.sysssispackages table. But we also have the project deployment model, which deploys an .ispac file into the SSISDB.
If you want a package to be in the SSISDB that is not of the project deployment model, the 2016(?) release of SSIS allowed for an Incremental package deployment for a project deployment model. You could use that approach to uplift your msdb based SSIS package into a new "project" without ever opening Visual Studio to create an actual solution.
That's a technical answer, it can be done that way but I would advise against it as you generally want to source control any processes that you operationalize.
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 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).
I'm developing a CMS and I'm using SQL Server with it. I want to automatically create my database in SQL Server 2008 when my app is installed.
I can generate a script. I'm wondering that there might be a way that I can install SQL script in a database using an MSI file.
e.g. in this link we can install database using a MSI file
http://www.microsoft.com/download/en/details.aspx?id=23654
I just wanna know how can we do it. Is it created using SQL Server or Visual Studio
you can attach a database through the app.config. in your installation you should copy this database to the right place.
Look here how to set your connection string:
http://www.connectionstrings.com/sql-server-2008