How to deploy a dacpac that contains a FULLTEXT INDEX (built from a database project) to SQL Server using msdeploy?
MSdeploy skips creation of the fulltext indexes, and fails when creating objects that depend on the (now missing) fulltext indexes.
Is there an hidden option to exclude/include creation of fulltext indexes?
We had same problem with deployment using sqlpackage. Root cause is order of statements on building deployment plan with switched on IncludeTransactionalScripts option. Depended objects deploy before full-text index.
Solution
So we just set
IncludeTransactionalScripts=False
when deployment has new full-text index.
Hope it helps.
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/
There are thousands of on-premises servers who are running all different versions of a piece of software including a specific version of a database (all at different companies)
Out of a central development department regularly new versions or pushed of the software with database updates (new tables, new views, new foreign keys, new inserts for enums or specific tables, new stored procedures, etc)
These changes come from many different development branches all bringing in their own bits of sql code that affects the schema
Updating client is handled via a .sql file which verifies the local installed latest database schema release version and the sql code that is annotated as later is ran to update a specific physical machine to a later version (automatically without user involvement)
An idea is now to instead use the EF SSDL description of the specific assembly distributed to bring a database schema (sql server) to the latest version. It would need to compare every table, column, constraint, etc to check if they are equal and if not update them taking into account dependencies.
Question: is there an existing package which would do this? So that e.g. when starting an application it would check the existing physical database versus the SSDL and brings them in sync automagically? It would have to skip database objects that are not in the SSDL since a database could contain tables or views which were added by a specific customer and is not part of the database objects needed by the application or is the current approach the best way to go? (in itself this is another approach than e.g. redgate with comparing the physical database) ?
(the only related question i found here is Purpose of edmgen validation? Comparing SSDL and database schemas?)
I am trying to use migrations with a existing database and to create a new one, if not exists.
The EF Core documentations says:
If you created the initial migration when the database already exists, the database creation code is generated but it doesn't have to run because the database already matches the data model. When you deploy the app to another environment where the database doesn't exist yet, this code will run to create your database
From EFCore docs
I did initial migrations, it creates a up and down methods to create my tables. When I run it to a new database (new database name in connection string) it creates the database and tables as expected.
But if I run it to an existing database (not created by migrations), it fails at the first up method that tries to create a table that already exists, and the migrations stops to run.
Docs says "it doesn't have to run", but first thing migrations is doing is try to create an existing table.
How to prevent migrations to try to create existing tables? There is something like "create if not exists" built in on migrations? Is documentations right? It should works as expected/describe in docs?
If I'm doing it wrong, what is the strategy to work with migrations to run with existing and new on databases?
Dotnet Core version: 1.1.
EFCore version: 1.1.2.
Thanks in advance.
You need a baseline migration for the existing database. In EF 6 you used the -IgnoreChanges flag, but that doesn't exist in Core right now. See here.
You can accomplish the same thing in EF Core by commenting out all the Up() code and applying that migration. This will create the __MigrationHistory table and insert a record denoting it has been applied.
Subsequent migrations will be applied to both and if you need to create a new database you are covered.
IMHO using maven for migrations is fine only for development machines.
On servers you don't usually have maven available (and it might be impossible to have it installed there).
So: How do I init a database without maven?
Do I just call flyway.init()?
What if the db is already init-ed?
Can I execute sql statements to init the db?
My foreign keys and indexes are different/messed up in between different databases instances, so I already made a complete schema script and tested it with data export, schema drop, schema re-create and data restore. I am going to do that on all databases to ensure that they are exactly the same.
Yes, you can simply call flyway.init()
You can use flyway.status() to check if the DB has been inited.
This process will become easier with Flyway 1.8, where a new property called initOnMigrate has been introduced. The first time it runs, it will then init an existing non-empty database (PROD) when you run migrate or just migrate on an empty one (DEV).
I have a number of manually written scripts (.sql) for tables, views and stored procedures that are used from an ASP.NET application. These scripts drop the object and recreates them. I need a way to update the database when the scripts change without deleting the object. For example, when a column is added to an existing table that has rows in it, I would need to update this table with this extra column without losing the rows.
I need a way to "update" the database on a single click (I can hook up the changes using a batch file). Does Visual Studio support this kind of functionality?
If you get Visual Studio Team System - Database Edition 2008 - which is now bundled with "Developer Edition" for free - it handles that. Visual Studio database projects without that edition really just store the static SQL that you want to track. The Database Edition is capable of determining the 'deltas' between your SQL and what's in a target database, generating that script, and executing against your database. You do get the option of reviewing that generated SQL, but by default it is very safe [it won't run if it thinks that there will be any data lost].
Yes - it's called Database Projects.
You can define a Visual Studio Database Projects, have create and change SQL scripts inside it, and then execute those against a database connection of your choice when you need to.
See this blog post here for a great explanation, or read the whole series that the 4 guys from Rolla wrote.