3

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?

Mansuro
  • 4,558
  • 4
  • 36
  • 76
Steve
  • 11,696
  • 7
  • 43
  • 81

2 Answers2

2

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.

David
  • 208,112
  • 36
  • 198
  • 279
  • so its only the schema that its updating, not the content. I asume it finds the old/new version of the DB from the connection string setting in web.config right? And is there a way to stop it from doing so? – Steve Oct 05 '14 at 22:20
  • @Steve: It would only update content if the source controlled scripts contained any content. A common example would be using `MERGE` statements in post-deploy scripts in the source code to maintain lookup tables. If all you're tracking is schema, all that would be updated is schema. As for the details of where it gets a connection string and such, that's going to depend on how you're tracking the changes. A database project? EF code-first models? Something else? If a database project, there's likely settings in the project properties. – David Oct 05 '14 at 22:48
  • Its a MVC web site project. No database included. I do have couple .sql files though..would it scan it? I just want to make sure that it will not ruin my production DB by injecting bunch junks from my local test data – Steve Oct 05 '14 at 22:51
  • @Steve: I'm not sure on the specifics then, I've always tracked DB schema/data in database projects. Though it's still worth looking at project properties and whatnot, there are likely some deployment settings there. Of course, if the feature isn't supported then it shouldn't do anything. One way to be really sure would be to not allow access to the production DB from the user context of deployments. – David Oct 05 '14 at 22:53
  • how can i not allow access to production DB from user context of deployments? – Steve Oct 05 '14 at 23:03
  • @Steve: Well, when you perform deployments you should do so as a user who can't make changes to the production database. And that code shouldn't have a connection string with such a user. Then regardless of what the tools may or may not be doing, if the production database doesn't allow changes from that user then the tool won't be able to make changes. Keep the production connection string separate from the development connection string, basically. – David Oct 05 '14 at 23:06
1

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

Razvan Dumitru
  • 11,815
  • 5
  • 34
  • 54