My Asp.net project uses an SQL db. I need to update the published version on Azure. It keeps failing on the db deploy. The thing is, all I need to update is the code. The current data are fine. Is there a way to tell it to go ahead and deploy the code and leave the data unchanged?
I figured it out. Under project settings, package/publish SQL, remove the database.
Related
I have a visual studio project which contains a database project. I create an executable which performs a software update and part of that update is to update the database. Some of the stored procedures are dependent on a linked server existing which gets created as part of the executable too. The problem is that this functionality is optional and the linked server won't connect on some client machines. But the DACPAC fails because the linked server can't connect. I am using sqlpackage.exe to deploy the .dacpac file.
Is there some way that I can deploy either all or only some of the stored procedures? Or maybe I can set a flag to ignore linked server errors? Or maybe there is an alternative method to using sqlpackage/dacpac?
One option I thought of is to convert the stored procedures that contain the linked server to dynamic SQL.
Having the database in visual studio and therefore source control is important.
Yes!
This is fairly easy to do. You can see your database project in visual studio. I would recommend removing the stored procs that are problematic and merging those back in to master. Then I would take out a feature branch and point again to the DB you have the stored procs on and use the schema compare to get those back as well (even the ones that don't work well so that you don't lose them). Push the commit up to the feature branch repo. Then,now that you have the problematic stored procs in source control + the shippable version in master-- you can go ahead and thruough visual studio "publish" through the database project into the DBs you want the selected objects.
If you haven't checked in anything to master-- you can do the schema compare and select all objects except those that are problematic and update your database project. and merge that to master. If this doesn't make sense, please comment on this answer and I'm happy to give more detail.
Well, I came across this. Still working on to implement this to solve my problem. Might help your cause too.
Download the filter from:
https://agilesqlclub.codeplex.com/releases/view/610727 put the dll
into the same folder as sqlpackage.exe and add these command line
parameters to your deployment:
/p:AdditionalDeploymentContributors=AgileSqlClub.DeploymentFilterContributor
/p:AdditionalDeploymentContributorArguments="SqlPackageFilter=IgnoreSchema(BLAH)”
This will neither deploy, drop or alter anything in the BLAH schema.
More details on
https://the.agilesql.club/2015/01/howto-filter-dacpac-deployments/
I am building an ASP.NET MVC EF app with code-first migrations and hosting it in Azure with Azure SQL DB. The first time I published this, it went fine. But since then my models changed, and my schema in the Azure DB is not getting updated to match. When I deploy, I do have "Execute Code First Migrations" checked. When that wouldn't work, I deleted my DB and then recreated it in the Azure portal, figuring that would trigger it getting updated. But then that didn't work, so I set AutomaticMigrationsEnabled = True in the migration Configuration. It is STILL not working, so currently my DB in Azure has none of my tables. HOW can I get the DB in Azure to be forced to update to match my models so the published site will work?? I did try looking for if there's a way to script the VS local DB to a Create query and execute that in SQL management studio, but couldn't find how to do that.
If you have made sure that you have selected update database in the publish setting, and the connection string is correctc and its still not updating. Maybe the following will help for you:
I sometimes get an issue like this, it is quite frustrating, My publish file is correct and my settings are set to allow SQL updates to occur during publishing. But sometimes the database hasn't been updated and I get a nice "backing context has changed" error, sometimes the culprit is the migration table that hasn't been updated. Unfortunately the only sure way to get your databases in sync is to check what migration history they are both at, by comparing [dbo].[__MigrationHistory]
If your published server is missing the latest migration history, then you can generate an SQL script of that by typing into the package manager console:
Update-Database -Script -TargetMigration [migration name]
'migration name' should be the name of the last migration that your published server had, visual studio will generate sql script that can be used to bring the database up to the latest migration from that target migration.
Sometimes (though very rarely, its only happened once or twice for me) the above doesn't work for whatever reason (usually because migration files have been deleted), if that is the case then its a good idea to script the whole database, and cherry pick the sql you need from that.
Update-Database -Script -SourceMigration:0
This will generate a script for every migration, you can then cherry pick based on the changes you've made. The 'latest' changes will be closer to the bottom of the file. every migrational change will start with an if check:
IF #CurrentMigration < '201710160826338_mymigration'
BEGIN
You can use this to pick the bits that you need, if you do pick the SQL be sure to include the update to the migration history. It will be at the end of the if block and look something like this:
INSERT [dbo].[__MigrationHistory]([MigrationId], [ContextKey], [Model], [ProductVersion])
VALUES (N'201710101645265_test', N'API.Core.Configuration', 'Some long checksum')
Including the migration history will ensure that visual studio doesn't have the problem again.
Hope this helps.
I need some clarification on when to register a Database as a Data Tier Application (DAC). I've looked at all the guides but am stuck on a few points.
The database is NOT registered
Build Database Project to produce DacPac
Publish the Database Project
Check "Register as a Data Tier Application"
Check "Block publish when database has drifted from registered version"
First time round, this works. It registers the database and succeeds.
However, on subsequent publishes is fails as it says the DB has drifted noting two users which have not changed.
Am I following the correct process? i.e. setting the Publish script to re-register each time?
What is the best practice for making changes? By changing the relevant .sql files in the Database Project and then building? The guides talk a lot about being able to version the DB using the DacPac but its not clear how. Should I rename each DacPac and commit it to TFS?
My next step is to publish the Database as part of the overall ASP.Net Solution. When I try to do that (it works fine when the DB publish is not included), it comes up with the following error
Web deployment task failed. (The SQL provider cannot run with dacpac option because of a missing dependency. Please make sure that DacFx is installed. Learn more at: http://go.microsoft.com/fwlink/?LinkId=221672#ERROR_DACFX_NEEDED_FOR_SQL_PROVIDER.)
However, I have all the required elements installed on the publishing machine. Do they need to be on the SQL Server or IIS VMs?
Any guidance would be much appreciated.
If you want to deploy your changes to a database using a dacpac you would need to register the database as a DAC. This basically creates a snapshot of the database at that point in time. You do this before making a change to create the initial snapshot and then after a deployment.
The reason you do this is to detect drift. Lets say you do a deployment and someone makes a change directly in that database, for instance changing the logic of a stored procedure, you would want to know about that change before making a subsequent deployment. If you deploy your dacpac and ignore this change it will revert their change to whats in the dacpac model. This is where drift occurs. You can generate an xml report on what has drifted through the sdk.
You can enable a setting to disable deployment if drift occurs so that you can retrofit those changes in the database directly in your source code. You would then need to re-register the database as a DAC to create a new snapshot.
Am I following the correct process? i.e. setting the Publish script to re-register each time? Yes
What is the best practice for making changes? By changing the relevant .sql files in the Database Project and then building? Yes
The guides talk a lot about being able to version the DB using the DacPac but its not clear how. Should I rename each DacPac and commit it to TFS? You can set a version within the databse. Have a look at the properties of the database project. You shouldnt rename the dacpac.
About the ASP.Net publish, I would need a bit more detail around the project structure and environment setup.
I have an application written in ASP.NET and using EF. I want to make a copy of the live database, have my application point to the copy, and be able to run the application against it as if it is live...but making updates to the copy.
I know I can manually copy the database and manually update the web.config files...but I'm wondering if there is a better, more automated method for achieving this with VS 2010?
Also, if there is anything I need to know about setting up a live/dev version of a database while using EF4.
You can switch the ConnectionString to point to the live or development database.
One way is to have different web.config files for debug and release builds.
Check out Web.config Transformation Syntax for Web Application Project Deployment
From my experience,
Setup 2 database connection entries in your config file, name one backup and leave the other ones name alone. Point your backup one to the backup db and when you want to run the backup, just change the names of the entries so the backup one is the actual name and the live one is named anything else.
Also, as for setting up different db versions - I'd just be careful that you don't update live by mistake!! and I've found it best to track changes to the db structure in a sql file so the live can be updated if needed or the backup can be rolled back if changes are made
I'm building a web application which soon I'll be promoting to production. This application has a login screen, as you know I used the integrated DB for developing. Now I want to move this database to a full SQL Server 2005. I'm using the aspnet_regsql.exe to create my membership tables and stored procedures in the SQL Server 2005 but I'm getting an error:
An error occurred during the execution of the SQL file 'InstallMembership.sql'. The SQL error number is 207 and the SqlException message is: Invalid column name 'FailedPasswordAnswerAttemptWindowStart'.
I google this for half of the day already and I can't seem to fine what's wrong, does anybody have ANY ideas on what am I doing wrong here? Any help will be really appreciate it.
The easiest way to deploy a brand new database to a remote server is to just publish the database from within Visual Studio. Once you do that you have the scheme and data all in one script. You then access your server either via a local SQL manager connection or a remote manager and run the script on your remote database.
The site 4GuysFromRolla has a nice little walk through with graphics which describe how to accomplish the publishing of your local database to your hosted one.
Good luck, and hope this helps you out some.
Go through the *.sql script file and see where that column reference is. Then you'll be able to see what exactly the script is doing to cause this error. My guess would be that it is getting caught up on referential integrity. If it is trying to create a foreign key constraint that that table/column does not exist then you'll see that error.
But back to the original question at hand. You don't need to recreate your whole database. That script file is to lay down the Membership for an empty database. If you have a working dev database you can just back it up and restore it to a production instance. No need to rebuild the membership database objects.