When I am publishing my site using Web Deploy in Visual Studio I see something like:
MySql.Data.MySqlClient is not supported for incremental database publishing.
I want to know what exactly would this technology do if it is supported?
Incremental database publishing is a deployment feature where the source code for the schema (new version) is compared with the live database schema (current version) to create a change script to upgrade the current version to the new version.
For example, if your schema has a table with a few columns and in the source code you add a new column definition, when publishing it would create a script to add the new column to the table.
It's not surprising that a database engine besides SQL Server isn't supported, since supporting other database engines would be a significant amount of work. All it really means is that you'll have to synchronize database changes yourself. MySQL may provide tools to help with this, but Visual Studio doesn't.
Incremental database publishing is used for versioning purposes. SVN can't really handle versioning for database schema like tfs can support.
If you're using incremental database publishing you can set up to keep the current database and just do the update, or to always recreate database.
Let's assume you want to declare sql variables like InitData, SeedData.
You can do this and you have access at some before and post publishing script. If your variable SeedData is true, you can seed some data in the post publishing script.
More info here: http://www.asp.net/web-forms/tutorials/deployment/web-deployment-in-the-enterprise/deploying-database-projects
EDIT: it's just the schema that's updated if you choose not to recreate your database when you publish
Related
We are working in a very big organization, many Databases (of many types), many schemas, many users.
Does LB has to work with some Source Control (for locking the files
when many users exist in the organization and using the same DB,
same Schema, etc)?
What is the best practice of working with LB in a very big
organization, many concurrent users?
Can SQLCL general sql format type or just xml format type?
Is there some integration with SQL Developer? I mean, suppose a user
changes an objects via sql developer, what happens then?
We get this type of question all the time, after folks get a handle of how to automate DB changes, next step is typically to add it into an existing CI/CD workflow.
Yes, Liquibase works with any source control. Most users are using
Git. But you can use Git, TFS, SVN, CVS... Once you are up and
running with Liquibase, you just need to make sure that your scripts
are in source control and you are good to go.
Besides 3rd party source control tools, Liquibase has tracking tables called "DATABASECHANGELOG" tables that keep track of the changes applied to your database when using Liquibase deployments.
Here is some more information about getting started and How Liquibase Works. https://www.liquibase.org/get_started/how-lb-works.html
Liquibase has one more table that it uses internally called "DATABASECHANGELOGLOCK" table.
This table was designed to prevent multiple Liquibase users running deployments concurrently - potentially leaving the Database in a bad state. Once the Liquibase deployment (the liquibase update command) is done, the "DATABASECHANGELOGLOCK" will allow the next Liquibase user to deploy.
You can use both SQL and XML formats (or even JSON and YAML formats).
When using SQL, you have a few options:
Best option is to use Formatted SQL changeLogs https://www.liquibase.org/documentation/sql_format.html
https://www.liquibase.org/get_started/quickstart_sql.html
You can use plain raw SQL files referenced from an XML changeLog
https://www.liquibase.org/documentation/changes/sql_file.html
When using XML, can find all the available change types (also called changeSets) available in the following page (on the left of the page)
https://www.liquibase.org/documentation/changes/
XML changeLog are more agnostic and sometimes can be used for different Database platforms when doing migrations. Also, many of the change types in XML have the ability to be rolled back automatically. The reason that this is possible with XML is because Liquibase uses it own built in functions to figure out inverse statements like "create table" to be "drop table".
For each of those changeSets you can find out if they are auto rollback eligible (at the bottom of the page). For example, create table changeSet will be Auto Rollback = yes.
https://www.liquibase.org/documentation/changes/create_table.html
I have been building my ASP.NET Core MVC web application since last year and there are currently 100 migration files in my project, as the database has evolved along with features and capabilities. My development / test database is obviously in sync with this migration.
Now, the time has come to create a Production environment, and I want to have an empty database with only the table schema. So, I just can't copy my test database to create a production database.
So, the question / dilemma I have regarding creating this Production database is as follows;
1. I can either create my Production database by running Add-Migration command (for which I need to delete existing migration files from the project), or
2. Create table schema in SQL Management Server, and keeping the __EFMigrationsHistory from test database
With [1], I am not sure how I will be able to manage my test database with this same project, going forward.
With [2], I am not sure if there is any drawback.
So, what is the standard or best practice for Production deployment?
You can certainly use Visual Studio to create or update database tables, but this would normally just be in your development environment.
If you are worried about the number of migrations you have, you still have the option of starting over by deleting them, and deleting your migration history (and manually deleting your tables and data) and creating a fresh 'Initial create' migration. If you do this you will probably want to export any test or config data first, or make sure you have a way to recreate it.
For the staging and production deployments, best to use SQL Server Management Studio to generate a script to build your tables. The database administrator - or you if it's just you - can create the database and run the script to generate the tables.
This is because staging and production environments tend to be more tightly controlled than development, so best to understand the processes that are most appropriate for the environment.
You need to check that your dev and staging/production SQL databases are set at a matching 'compatibility level', and also need to decide whether you need to add any seed or configuration data on create.
In SQL Server Management Studio, select the appropriate option to generate a script for the required tables.
https://learn.microsoft.com/en-us/sql/ssms/scripting/generate-scripts-sql-server-management-studio?view=sql-server-ver15
You can also use this process to export, and import data - this is ideal for config or test data.
https://dzone.com/articles/generate-database-scripts-with-data-in-sql-server
I am using Talend Open Studio for MDM and I have a requirement to do version control on customer records.
When using an Oracle database, I can use tOracleSCD to capture the changes. Likewise, for MySQL, I can use tMysqlSCD.
But in Talend Open Studio for MDM, the only supported database is H2 and so I am storing all master records in a H2 database.
In this case, how can I achieve version control as there is no component available in Talend
for H2 database?
The SCD components just set up triggers on the watched tables and provide an easy interface into reading the trigger output tables.
You could set the triggers up manually on the H2 database by recreating the database in MySQL and then using the MySQL SCD components to work out what it's doing and work out how to read the data back in and then recreate those steps with H2 components as part of a data integration task.
That said, Talend MDM has the concept of a journal which stores all of the changes made to a data record. The Talend Open Studio for MDM documentation has some more detailed information about how to view the journal. All changes made through the MDM interface should make an entry in the journal automatically.
I recently moved my screwturn installation to a completely new environment (site on new IIS/server and database moved to new SQL Server).
I can succesfully open the Screwturn wiki but instead of using the existing database (that I configured in the web.config), Screwturn wants to create the DB from scratch and hence states the error that certain tables already exist in the DB.
If I create a blank DB and use this in the web.config, Screwturn will happily create its tables and use that DB. Of course, that's not what I want, I want it to use the existing, moved DB on the server.
Is there a way to tell Screwturn not to create the DB and simply "use" the existing one?
If this is not possible, are there scripts available to copy the content from the old DB to the new one (simply copying it with SQL Servers Import/Export feature gives errors (logical) that certain fields cannot be created as that will cause PK violations.
Did you use your old web.config or just update the SQL connection info in the web.config from the new version? I think you should use your old web.config (maybe compare to the new one to see if anything was added). I have done this several times with several installations and haven't had a problem.
The only other thing I can think of off-hand is if your old version is v2, then you should review the instructions here as a few things changed from v2 to v3.
Old Screwturn Wiki Site - Upgrade from v2 to v3
I have an ASP.NET MVC 3 application using an Entity Framework (4.3.1) Code First database. Now I would like to create a comprehensive zip file containing the database, the application package generated by Visual Studio 2010 and a script to deploy everything to a Windows 2008 server with IIS7 and SQL Server 2008 with a prepared (but empty) database.
I don't foresee any problems with the deployment of the application package, but I'm unsure of what approach to use in deploying the database. The target environment already has an empty database that's been assigned to me, but I've been told that dropping and creating the database is fine.
From what I've read, I can do a straightforward copy of the .mdf and .ldf files to the server and then setup my connection string to point to that specific file but this approach sort of ignores the database that has already been created (or at least named) for me. The other approach would be to use the the existing .mdf to create the database on the server with a script. My only issue here is that I would like to keep the database name assigned to me.
I usually connect to my development database locally using SQL Management Studio and right-click the database, choose Tasks -> Generate Scripts. Then I select the entire database or just the tables I'd like to keep, click next, then click the Advanced button and make sure that I am scripting out "Schema and Data", and then generate a sql script that I can run on the production database, therefore keeping the table structure and the data that was in the dev database. Obviously, if you don't want to keep the data then just script out the Schema only. Then, point your application's connection string to the new production environment database and you're good to go.