Is there a way to generate change scripts from a Visual Studio and TFS project? I would like to either choose two versions of the database or enter a date range and get change scripts that I can pass off to a DBA to apply to the production database.
I do not have access to the production schema in order to do a schema compare.
My DBA wants SQL scripts and will not use snapshot method.
I am using Visual Studio 2013 and SQL Server 2008 and later.
Help!
I would suggest that your dba's attitude is blocking your ability to deliver high quality software on a regular cadence. Comparing with production is the correct and supported method to achive a change script. And remember the tools you are using are built and supported by the SQL Server team.
If you know when the current production version was shipped you can create a workspace and get that specific version of your code. If you compile it you should have a .dacpac for that version and you can use that in the compare.
Another option would be to ask the DBA to restore the last production version to another server so that you can 'test' the script. You can then generate your script from there.
Whatever you choose you need to raise this with management as a blocker for continuous delivery.
Related
I need to understand what a certain job in SQL Server 2012 does. It's a job someone created and left the company before I started to work here, and nobody on my team knows what this job does also.
The job isn't SQL command based but SSIS Package (which I'm not familiar with), the package points to a Maintenance Plan with the same name as the job. As I read on the internet I connected via Integration Services type, then Stored Packages -> MSDB -> Maintenance Plans, right click on the Maintenance Plan and exported it to a .dtsx file.
I opened it in Visual Studio 2010 Shell, but I can't edit anything because of this error:
The task with the name "" and the creation name "" is not registered for use on this computer.
I also don't have a Solution Explorer for that package, and the icons of the tasks seem a bit faded compared to tasks icons of a new project if I create one.
Maybe the dated version of the VS can be the problem? Perhaps there is other way to see what this job does?
I never worked with SSIS before so maybe I'm missing something very basic but I've been on the Internet for days already and can't find any solution.
Please help,
Thanks in advance
By way of background, until Visual Studio 2019, VS, by itself, couldn't open an SSIS package.
Prior to VS 2010, you needed to use a different product, called Business Intelligence Design Studio (BIDS), which was based on VS, but was built for SQL Server functionality. With the release of SQL Server 2012, Microsoft created SQL Server Data Tools (SSDT) as a plugin for VS that required a separate installation. Until SSDT(VS) 2017, you needed to have stand-alone versions of BIDS or SSDT for each version of SSIS you were working with in your environment. The 2017 version, though, is backward compatible to SQL Server 2012, and forward compatible (!) to SQL Server 2019. Visual Studio 2019 has SQL Server Data Tools sort of built in, but you need to add extensions through the extension manager for SQL Server Integration Services (SSIS), Analysis Services (SSAS), and/or Reporting Services (SSRS).
That's kind of a lot to take in, and is sort of irrelevant to you, but it forms the context for Larnu's comments. Rather than messing around with antique versions of Visual Studio, you should just install either VS2017 and also SSDT, or VS2019 with the SSIS extension. Both are in current widespread use, so support is easy to find, and either will allow you to work with the 2012 package you're trying to open up.
Once you have the software installed, you should be able to create a "dummy" integration services solution that you can use to open random packages. I keep one around called MiscSolution. Right click on the solution name, select Add -> Existing Item. Then find your .dtsx package and import it. (Or right click SSIS Packages -> Add Existing Package. I always do it at the Solution level because that interface allows you to select multiple packages.)
Note that when you do this, you're making a new copy of the package in your local solution directory. You are NOT working on the copy of the package that sits in the folder where you picked it up. This matters if you're going to be making any changes, since it will need to be redeployed. It also matters if you accidentally hose up the package, because you've done no harm as long as you just delete that copy.
Once the package imports, which might take a minute or so depending on how complex it is, you should be able to open it up and see what's going on.
Me and my team are developing a SQL Server database. We want to work on different PCs, but with the same database. Is it possible that we can synchronise our work on each PC, or share our database while working somehow?
If possible how can Team Foundation server be used for that?
You can use SQL Server Database Tools (SSDT) to represent your database as a series of scripts. These scripts can then be added to source control. Git is by far the most popular source control system there is and Team Foundation Server and Visual Studio Team Services have great Git support.
Each developer will use Visual Studio (or VS Code) on their own machine to do their database work. When the developer wants to share their changes, they commit them to source control. Other developers can then update their local version of the code with the new changes. SSDT adds support for bringing your database and database project in sync.
Now that your code is in source control you can go a step further and add things like continuous integration builds and automated deployments with VSTS Build and Release Management. That way you can automatically test database changes and even run unit and integration tests before deploying to test and production environments.
The following Channel9 video gives an introduction to these tools: Database Continuous Integration and Deployment with Visual Studio SQL Server Data Tools in < 10 minutes
If you only care about schema changes (and not data changes), you can use visual studio's SQL Server projects, and a source control system, to help manage this. You can then use the Schema Compare tool to compare your project to the server, the server to your project, or server to server.
There are some tools from the likes of Redgate, etc, that allow this process to be automated. I've not used those, but they may be another option.
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).
Hey, I've just finished writing a VB.NET application. Now I want to package the executable and the database ofcourse into a single installer file. I tried using QSetup, InstallShield to make SQL Server embedded into the setup file, and finally after hours of try&fail I have no idea. Anyone?
You can do a rightmouse on the properties of your Visual Studio Setup Project, and then there is this button 'Prerequisites'. There you can tick 'SQL Server Express ...' Or the 'SQL Server Compact 3.5'
link to image
You're probably best off just to set the connection file directly to the mdf, and attach it when the program is run. This is easier as it doesn't require a custom setup script to install the database to the database directory itself.
Note: Consider using the Compact Version, it's smaller, people don't like a full blown engine on their computer :)
InstallShield has a concept called Setup Prerequisites where you can teach it how to install additional packages along with your own. In older versions this would happen before calling your MSI. In newer versions you can have a "Feature" prerequisite where the prereq can associated to a feature and only installed if that feature is selected to be installed and after it's been selected but still before the main activity of your MSI occurs during the install execute sequence.
InstallShield also has a pattern for executing SQL scripts against your database instance so that you can then load your database into your newly installed instance.
All of this is quite powerful but it does take a bit of digging to learn.
As far as I know, anything but the SQL Server Compact Edition (SQL Server CE) cannot be embedded into your setup, really. Microsoft doesn't want that - you need to have SQL Server Express installed separately - any other edition can't even be shipped with your software (the client must have a license and installation separately).
You can indeed distribute SQL server with your custom application:
http://msdn.microsoft.com/en-us/library/bb264562(SQL.90).aspx
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.