I am trying to relate Migrations History entries to version of software by which migration was performed. So far best place for that seems additional column in Migrations History table which can be filled with software version against each migration.
This article nicely describes how to make it, however it states:
Before you start you need to know that you can customize the
migrations history table only before you apply the first migration.
I don't believe this. Is there any way of achieving this? Maybe it is possible to change this table within another migration, however I am not sure about consequences, can anyone please advice on this matter?
Related
I have a project using EF migrations, I just need to confirm if we need to adjust anything or maybe a parameter in case more than one person is doing changes on the DB project. For example, yesterday a coworker was adding a column in a table and pushed the changes on the git project. I did get latest and today I need to do another db change in another table and when I create a new migration, the script is pushing the change my coworker did. Is there any wrong in the configuration?
I am using postgres for my database and because our product is in development mode, sometimes we need to change our database scheme. If we find some problem in that we need to revert our changes, We have to do this manually. Although we have a option to make database backup before making any change. But I was looking for some solution more kind of git. So, that we don't have to do this manually.
I would suggest you script the creation of your database. Save this SQL script in a SqlScripts directory at the base of your project and check this into source control with the rest of your project. Then if you need to alter your database schema, you alter or add to you SQL script or scripts. In that way the structure of your database is versioned but the data is not in source control, which you would not typically want to do.
One short-coming here is you may have to manually run this script when reverting commits, but this isn't a situation that should happen too often.
Using SQL Management Studio (the latest version, with SQL Express), I enable change tracking on a database and some of its tables.
If I ever need to edit the columns of one of this tables where change tracking is enabled, I will have to re-enable change tracking manually on this table afterward.
Is there any way to have change tracking automatically re-enabled after an edition to the table structure ?
I don't think so, but if you can afford to lose some of the data you could set up a job to run periodically and re-enable it. You should also extract the CT data and archive it somewhere before you make the table change.
We are working with Code First Migrations EF 5.0.0.rc and we are having problems when two people on the team create migrations at the same time and then commit their changes.
This looks because the Update-Database compares again the latest migration model hash or something that does not have my changes because it was commited by someone else. So is based in the database state of the latest migration, and then ignoring the changes I already applied previously.
This is a very ugly behaviour when working with local databases to simplify development and remote work. I guess this should work different, always using the current model for comparison and not the latest one declared in the Migration file model hash.
Or we are doing something wrong? Anybody with this issue?
The migration tool is really awesome, but it's very difficult to work on diverse environments, remote without this feature working fine and we are struggling our head because this looks very basic feature.
Thanks,
Leonardo
This is a very strange problem. I've asked about it before here:
How did my trigger get deleted?
I renamed my trigger and I thought it had stopped happening but the problem seems to have come back again.
I've added a trigger to a table in our database. The server is SQL 2008. The trigger doesn't do anything particularly tricky. Just changes a LastUpdated field in the table when certain fields are changed. It's a "After Update" trigger.
There is a large C++ legacy app that runs all kind of huge queries against this database. Somehow (I've got absolutely no idea how) it is deleting this trigger. It doesn't delete any other triggers and I'm certain that it's not explicitly dropping the trigger or table. The developers of this app don't even know anything about my triggers.
How is this possible?
I've tried running a trace using SQL Server Profiler and I've gone through each command that it's sending and run them using SQL Management Studio but my trigger is not affected. It only seems to happen when I run the app.
The other devs reckon that they are not deleting it explicitly. It doesn't exist in sys.objects or sys.triggers so it's not a glitch with SSMS. Guess I'll just rename it and hope for the best? I can't think of anything else to try. A few comments below have asked if the trigger is being deleted or just disabled or not working. As I stated, it's being deleted completely. Also, the problem is not related to the actual contents of the trigger. As I stated, it I remove the contents and replace with some extremely simple code that doesn't do anything then it is still deleted.
Look for table drops -- you might be surprised at what actually causes your table to be dropped. (Different things you do through the SSMS UI, as opposed to using tsql directly.)
You can prevent this kind of inadvertant table dropping like this:
Tools -> Options -> Designers-> Uncheck "Prevent saving changes that require table re-creation"
Perhaps you could create a DDL trigger on the database and log all the object deletion statements. In particular, you could write the drop events to a table to log to trace it or just flat out block it.
Is other application code dropping and re-creating the entire table ? If so, perhaps it is not aware of the trigger.
Thanks for the suggestions everyone. In particular Billinkc's suggestion of creating a DDL trigger was cool. I didn't know that such a thing exists.
Anyway after three months of wondering what was going on here I finally got to the bottom of it.
I have a bunch of scripts to create various triggers. They have the typical format of "if trigger exists then delete", "go", followed by "create trigger" and another "go". I use a script to add all these individual triggers to the database in one go. I missed one of the "go" commands at the bottom of a create command (in all these hundreds of lines). This means that trigger A got added to the database with "if trigger B exists then delete" at the bottom of it. That was so confusing...