SqlPackage.exe ignores its CreateNewDatabase property? - deployment

In VS 2013, have two SSDT composite projects that target the same database:
The 1st project is responsible for the target database itself.
The 2nd project has a database reference to the 1st project and is responsible for test data in the target database.
When I deploy the 2nd project, I only want to update the target database as needed, never drop/create it.
To deploy the 2nd project, I am attempting to use SqlPackage.exe as follows to generate a deployment script:
C:\some\directory\ssdt\sqlpackage.exe ^
/a:Script ^
/op:".\BlahTest.sql" ^
/sf:".\BlahTest.dacpac" ^
/tsn:"localhost" ^
/tdn:"BlahTest" ^
/p:CreateNewDatabase="False" ^
REM ...
I expected /p:CreateNewDatabase="False" to mean that I would not find DROP DATABASE or CREATE DATABASE in BlahTest.sql; but I see the following irrespective of the CreateNewDatabase property (i.e. set to "False", set to "True", or omitted):
USE [master];
GO
IF (DB_ID(N'$(DatabaseName)') IS NOT NULL)
BEGIN
ALTER DATABASE [$(DatabaseName)]
SET SINGLE_USER WITH ROLLBACK IMMEDIATE;
DROP DATABASE [$(DatabaseName)];
END
GO
PRINT N'Creating $(DatabaseName)...'
GO
CREATE DATABASE [$(DatabaseName)]
ON
PRIMARY(NAME = [$(DatabaseName)], FILENAME = N'$(DefaultDataPath)$(DefaultFilePrefix)_Primary.mdf')
LOG ON (NAME = [$(DatabaseName)_log], FILENAME = N'$(DefaultLogPath)$(DefaultFilePrefix)_Primary.ldf') COLLATE SQL_Latin1_General_CP1_CI_AS
GO
How can I get SqlPackage.exe to output a script that does not drop/create the target database?

The CreateNewDatabase flag just determines whether to always do a full drop and recreate when publishing - perhaps the SqlPackage.exe documentation isn't clear enough about this? It states that CreateNewDatabase "Specifies whether the target database should be updated or whether it should be dropped and re-created when you publish to a database." The assumption is that if you're choosing to publish, you want the database to be created no matter what.
You can't do what you want using just SqlPackage.exe but it would be very easy to write your own code to do it. See this answer on how to check if a database exists for sample code checking if a database exists. You could write a powershell script that does this check and calls into SqlPackage.exe if CheckDatabaseExists is true.

Related

PG::DuplicateTable: ERROR: relation "boards" already exists

I created a model in no2 branch, then I find some error and decided to delete this branch and start a new one.
But when I rewrote this model and db:migrate , it told me that this table already exist.
I tried db:rollback but didn't work, and the migrate:status showed that:
and my schema.rb is empty
I dropped my db & re db:migrate.
Use sql script, to remove a record from schema_migrations table where version is 20191215065743.
Further, if the boards table exist, drop it using psql command.

How to recover from Entity Framework nightmare - database already has tables with the same name

How do you get EF back in Sync with code without losing data when Update-database returns the following message
Error Message: System.Data.SqlClient.SqlException (0x80131904): There
is already an object named '' in the database.
I originally wrote this as a self-answering question as I had struggled with the proble for some time, as had a few colleagues, but unfortunately, my answer was deleted and I can't recover it.
Since it's a situation that I suspect can happen several times as people try to "clean up" old migrations, I thought I'd document it with step by step instructions.
Description of the situation we found ourselves in:
We couldn't can't create a new local database because the init script was incomplete, and couldn't apply updates to the production database because the migration scripts create tables that already exist. And, we didn't want to delete production data.
Symptom: Can't run Update-Database because it's trying to run the creation script and the database already has tables with the same name.
Error Message: System.Data.SqlClient.SqlException (0x80131904): There
is already an object named '' in the database.
Problem Background:
To understand this in more detail, I'd recommend watching both videos referenced here:
https://msdn.microsoft.com/en-us/library/dn481501(v=vs.113).aspx
To summarise, EF understands where the current database is at compared to where the code is at based on a table in the database called dbo.__MigrationHistory. When it looks at the Migration Scripts, it tries to reconsile where it was last at with the scripts. If it can't, it just tries to apply them in order. This means, it goes back to the initial creation script and if you look at the very first part in the UP command, it'll be the CreeateTable for the table that the error was occurring on.
Solution: What we need to do is to trick EF into thinking that the current database is up to date, while "not" applying these CreateTable commands since the production database already exists. Once production DB is set, we still need to be able to create local databases as well.
Step 1: Production DB clean
First, make a backup of your production db. In SSMS, Right-Click on the database, Select "Tasks > Export Data-tier application..." and follow the prompts.
Open your production database and delete/drop the dbo.__MigrationHistory table.
Step 2: Local environment clean
Open your migrations folder and delete it. I'm assuming you can get this all back from git if necessary.
Step 3: Recreate Initial
In the Package Manager, run "Enable-Migrations" (EF will prompt you to use -ContextTypeName if you have multiple contexts).
Run "Add-Migration Initial -verbose". This will Create the initial script to create the database from scratch based on the current code.
If you had any seed operations in the previous Configuration.cs, then copy that across.
Step 4: Trick EF
At this point, if we ran Update-Database, we'd be getting the original error. So, we need to trick EF into thinking that it's up to date, without running these commands. So, go into the Up method in the Initial migration you just created and comment it all out.
Step 5: Update-Database
With no code to execute on the Up process, EF will create the dbo.__MigrationHistory table with the correct entry to say that it ran this script correctly. Go and check it out if you like.
Now, uncomment that code and save.
You can run Update-Database again if you want to check that EF thinks its up to date. It won't run the Up step with all of the CreateTable commands because it thinks it's already done this.
Step 6: Confirm EF is ACTUALLY up to date
If you had code that hadn't yet had migrations applied to it, this is what I did...
Run "Add-Migration MissingMigrations"
This will create practically an empty script. Because the code was there already, there was actually the correct commands to create these tables in the initial migration script, so I just cut the CreateTable and equivalent drop commands into the Up and Down methods.
Now, run Update-Database again and watch it execute your new migration script, creating the appropriate tables in the database.
Step 7: Re-confirm and commit.
Build, test, run. Ensure that everything is running then commit the changes.
Step 8: Let the rest of your team know how to proceed.
When the next person updates, EF won't know what hit it given that the scripts it had run before don't exist. But, assuming that local databases can be blown away and re-created, this is all good. They will need to drop their local database and add create it from EF again. If they had local changes and pending migrations, I'd recommend they create their DB again on master, switch to their feature branch and re-create those migration scripts from scratch.

Forcing a failed mvn flyway:migrate to skip failed schema migration, and try executing next schema

I was trying to run flyway:migrate on my projects postgres database. I have made the changes to a table manually and because of that the schema migration using flyway is failing, which is blocking next schema migration execution.
table : foo
required_change : ALTER TABLE foo ALTER COLUMN id DROP NOT NULL
current_schema_version : 2
next_schema_version : 3
Error:
[ERROR] com.googlecode.flyway.core.api.FlywayException: Migration of schema "public" to version 3 failed! Changes successfully rolled back.
How could I skip failing schema and make flyway:migrate execute next schema defined?
It might be simplest to undo the manual change so that Flyway can run successfully. For example, if you dropped the column then add it back in, then run the Flyway script to drop it.
So I found one possible solution to this problem, which goes as follows:
(1). In mysql database there is a table schema_version, which maintains the migration version number , it's status and other related information.
for ex.
mysql> desc schema_version;
version_rank
installed_rank
version
description
type
script
checksum
installed_by
installed_on
execution_time
success
for a failed migration the success field values stores 0, to override that and execute the next flyway:migration you can manually set the value to 1 (this would make sure, you don't lose the data stored on the table you created manually , when migration failed.
(2). Adding following on your pom.xml while running flyway:migration temporarily (while testing) also helps.
<validateOnMigrate>false</validateOnMigrate>

Rename SQL Azure database?

How can i rename the database in sql Azure?
I have tried Alter database old_name {MODIFY NAME = new_name} but not worked.
Is this feature available in SQL Azure or not?
Just so people don't have to search through the comments to find this... Use:
ALTER DATABASE [dbname] MODIFY NAME = [newdbname]
(Make sure you include the square brackets around both database names.)
Please check that you've connected to master database and you not trying to rename system database.
Please find more info here: https://msdn.microsoft.com/en-US/library/ms345378.aspx
You can also connect with SQL Server Management Studio and rename it in Object Explorer. I just did so and the Azure Portal reflected the change immediately.
Do this by clicking on the database name (as the rename option from the dropdown will be greyed out)
Connect with SQL Server Management Studio to your Azure database server, right-click on the master database and select 'New Query'. In the New Query window that will open type ALTER DATABASE [dbname] MODIFY NAME = [newdbname].
It's Very simple for now - Connect to DB via SQL Management Studio and Just rename as you generally doing for DB [Press F2 on DB name]. It will allow you to do this and it will immediately reflect the same.
I can confirm the
ALTER DATABASE [oldname] MODIFY NAME = [newname];
works without connecting to master first BUT if you are renaming a restored Azure database; don't miss the space before the final hyphen
ALTER DATABASE [oldname_2017-04-23T09 -17Z] MODIFY NAME = [newname];
And be prepared for a confusing error message in the Visual Studio 2017 Message window when executing the ALTER command
Msg 0, Level 20, State 0, Line 0
A severe error occurred on the current command. The results, if any, should be discarded.
You can easily do it from SQL Server Management Studio, Even from the community edition.

TSQL syntax to restore .bak to new db

I need to automate the creation of a duplicate db from the .bak of my production db. I've done the operation plenty of times via the GUI but when executing from the commandline I'm a little confused by the various switches, in particular, the filenames and being sure ownership is correctly replicated.
Just looking for the TSQL syntax for RESTORE that accomplishes that.
Assuming you're using SQL Server 2005 or 2008, the simplest way is to use the "Script" button at the top of the restore database dialog in SQL Server Management Studio. This will automatically create a T-SQL script with all the options/settings configured in the way you've filled in the dialog.
look here: How to: Restore a Database to a New Location and Name (Transact-SQL), which has a good example:
This example creates a new database
named MyAdvWorks. MyAdvWorks is a
copy of the existing AdventureWorks
database that includes two files:
AdventureWorks_Data and
AdventureWorks_Log. This database uses
the simple recovery model. The
AdventureWorks database already
exists on the server instance, so the
files in the backup must be restored
to a new location. The RESTORE
FILELISTONLY statement is used to
determine the number and names of the
files in the database being restored.
The database backup is the first
backup set on the backup device.
USE master
GO
-- First determine the number and names of the files in the backup.
-- AdventureWorks_Backup is the name of the backup device.
RESTORE FILELISTONLY
FROM AdventureWorks_Backup
-- Restore the files for MyAdvWorks.
RESTORE DATABASE MyAdvWorks
FROM AdventureWorks_Backup
WITH RECOVERY,
MOVE 'AdventureWorks_Data' TO 'D:\MyData\MyAdvWorks_Data.mdf',
MOVE 'AdventureWorks_Log' TO 'F:\MyLog\MyAdvWorks_Log.ldf'
GO
This may help also: Copying Databases with Backup and Restore