i was working on an application and drop/creating the database on each launch. Now, before going into production, i enabled migrations. I created an initial migration, then changed one of my models, added a new migration, updated the database, and everything was dandy
now, I tried to change the database name in the context, to see how it would behave on a new database, and every time I launch the application I get a differed exception.
right now its "invalid object name".. on one of my tables i think. I'm looking at answers here and they say to refresh the intellisense cache but I can't find where. I went to edit -> intellisense -> theres no refresh cache, theres refresh remote resources, which didn't fix anything.
by the way, do I have to turn automatic migrations on? (i.e. 'true')
Related
I have added code to cache Db for my Yii2 application, it works perfectly as expected, but the problem I am facing due to that is, everytime I add any new column to the Db, application complains about the missing column due to caching mechanism. So I have to every time either add Yii::$app->cache->flush(); into my migration file manually or clear it from server, which is kind of annoying and I might miss that. Is there any way to automate this, like add this line at end of every new migration created automatically?
We have a Web Forms app using VB.NET. When we first started the project a couple years ago, we though DB Migrations was a great idea! However, the actual use of it was not as grand. So we tried to disable it. We followed the steps as outlined in the dozen or so articles including:
Remove the Migrations folder
Remove the __MigrationHistory table
added Database.SetInitializer(Of MyContext)(Nothing) to the constructor of MyContext
I have not found any form of "Disable-Migrations", only re-enabling migrations with more parameters which makes new config files and reinitializes migrations.
Even with all of this, EF keeps querying the database for the __MigrationHistory table which it can't find, so throws an error Invalid object name 'dbo.__MigrationHistory'.
How can we completely remove Migration History so EF stops using it?
I'm using MigratorDotNet to manage Rails-style migrations for my web app. I have a workflow where, if I delete all the tables in the database, I can access an installation view that will run MigratorDotNet and create all the necessary tables.
This works locally. For some reason, when I upload my code to my Arvixe hosting, the migrations just never run. I get this odd error:
There is already an object named 'SchemaInfo' in the database.
This is odd because, prior to running migrations, I manually deleted all the tables in the database (to make sure it wasn't left over from a previous install).
My code essentially boils down to:
new Migrator.Migrator("SqlServer", connectionString.ToString(), migrationsAssembly).MigrateToLastVersion();
I've already verified by logging that the connection string is correct (production/hosting settings), and the assembly is correctly loaded (name and version).
Works locally, but not on Arvixe. How do I troubleshoot this?
This is a dark day.
It turns out (oddly) that the root cause was my hosting company used a schema other than dbo for my database. Because of this, the error message I saw (SchemaInfo already exists) was talking about their table.
My solution, unfortunately, was to rip out MigratorDotNet and go with FluentMigator instead. not only did this solve the problem, but it also gave me a more intelligible error message (one referring to the schema names).
While it doesn't seem possible to auto-set the schema, and while I need to switch the schema on my dev vs. production machine, it's still a solvable problem (and a better API, IMO). I googled, but did not find any way to change the default schema in migratordotnet.
I'm sorry for the issues that you were having. On shared hosting, unfortunately the only way that we may be able to change the schema is manually. If you are still looking for a solution that requires our assistance, please forward your ticket ID to qa .at. arvixe.com as well as arvand .at. arvixe.com and we can look into the best way to resolve this.
My web app has a self-installation process; it detects (correctly) that the database isn't initialized, and initializes it (via migrations); I also have automated integrational tests that test installation works under these circumstances, and smoke-tests logging in and registering the first user (provided on the installation form).
I recently switched from MVC3 to MVC4. I used the built-in storage provider (in MVC3, the aspnet_* tables; in MVC4, WebSecurity with the UserProfile table).
Instead of hand-running all the MVC3 stored procedures from a .SQL file, I now have calls to WebSecurity.InitializeDatabaseConnection. In fact, my code snippet is:
if (!WebSecurity.Initialized)
{
WebSecurity.InitializeDatabaseConnection("ApplicationServices", "UserProfile", "UserId", "UserName", true);
MigrationsWrapper.MigrateToLatestVersion(); // wrapper around migratordotnet
}
Unfortunately, I've noticed an interesting "bug." When I compile my server code and run my installation tests, it passes (as expected) after a fresh install (empty database). If I immediately run the tests again, it fails.
The reason for failure? In my installation test, I nuke all the DB tables, and expect installation to recreate them. However, in this case, WebSecurity.Initialized returns true instead of false. So, I never hit the second line (initialize and create tables). If I move that line outside, I will get an exception that I'm double-initializing.
Unfortunately, what I really need here is a method like WebSecurity.CreateTables(), which doesn't exist. I am therefore quite stuck at an impasse. How do I handle this?
Also, if I try recreating the UserProfile table myself, I run into an issue with UserId (primary key) being inserted as null -- presumably because I'm missing the other tables.
How should I handle this scenario?
The only work-around I have right now is to reset IIS. Sad, but true; doing this will reset WebSecurity.Initialized and everything works.
Since I need to at app start, I can programatically reset IIS with Process.Start.
I have set up a RavenDB for evaluation. I wrote some code which pushed some documents into it. I then have a web site which renders those documents.
Throughout the day, I used the Raven Studio to modify some text in those documents, so that I could see the changes come through in my web site.
Problem: It seems that after going home for the night, when I come in the next day my database has changed - my documents have reverted to the 'pre-changed' versions... what's going on??
I've looked through the Raven console output, and there were no update commands issued on my developer machine overnight (nor would I expect there to be!!)
Note: this is just running on my development machine.
As far as I know, RavenDB has no code in it that would automatically undo commited write operations and honestly, this would really scare me. Altogether this sounds really weird and I can't think of a scenario where that could actually happen. I suggest you send the logfiles to ravendb support if it happens again, because this would be a really serious issue.
My colleague had this very problem with updates being reverted. The update we made was to add a property, and then also a document specific value for this property, to all the documents. We called SaveConfiguration() and saw the change being done in the Raven Studio. A while later some of the documents had lost it's new property.
I decided to turn on the logging and therefore added an NLog.config file, to get the logging started I touched the web.config. This of course restarted the application, and "voila", the updates appeared in the Raven Studio again.
After a while they disappeared from the Raven Studio, so I assumed that this was a studio problem. I therefore tried to retrieve the objects from the database in a test controller, unfortunately the objects were lacking the property value here too, so it wasn't just a studio problem.
With the logging turned on we updated the documents of the specific type again, and according to the logs and also the studio we actually updated the documents. Not long thereafter the documents reverted by losing it's added property yet again (my colleague started crying at this point - true story)..
Later I came to realize that this was all because of our live web application still had the old version of the object. When it was read in the web application the data was returned without the extra property. Because of this it seems like our DocumentSession thought that the object had changed (in all fairness), so when we called SaveChanges even these objects was written to the database - without it's extra property.
Is my conclusion correct? What is the solution to this problem? I'm thinking CQRS, because then we will never call "SaveChanges()" on the DocumentSession for reads.
Adam,
Just making sure, did you call SaveChanges() after you made your modifications?
There is absolutely nothing in RavenDB that would cause this behavior.