I am trying to replace sql server with sqlite as database in aspnetboilerplate following this tutorial. we have to remove previous migrations and add new one before running "update-database" but it gives empty database and running this project gives error " 'SQLite Error 1: 'no such table: AbpEditions". how to populate newly installed sqlite database?
there are SeedHelper.cs and initialHostDbBuilder.cs files in EntityFrameworkCore project, probably for seeding database but i could not figure out how to use them?
Make sure that config files in all of your projects that need the access to the database are pointing to the same file. If you have just used the value from the article
"Default": "Data Source=SqliteDemoDb.db"
then you have a separate database file in each project. The file that the migrations are executed on is in the EntityFramework project.
Related
I am using Code First, and I want to migrate it to ORACLE database, after multiple migrations process, I am getting this error,
The best overloaded method match for Oracle.ManagedDataAccess.EntityFramework.OracleMigrationSqlGenerator.Generate(System.Data.Entity.Migrations.Model.CreateTableOperation) has some invalid arguments
I'm facing the same problem
finally I solve it by opening the database and delete the migration_history table manually
and run the command again.
see at EF5 Code First - Changing A Column Type With Migrations
in each migration you will save a record in __MigrationHistory, so in case there is no sync between the code and the migration do the following:
delete the migration history table in the database.
migrate it again by create new migration 'in package manager console' add-migration data.
update the migration to database update-database
I have created the schema through MySQL Workbench and synchronized it with the database.
All the tables are there in database. Now when I use the
php artisan migrate
command, is there an option to take the fields director from the database instead of specifying the fields name.
Also could you please suggest any other tools on github.
Laravel Migrations Generator will help us generate migration source code from existed database in Laravel 4.
so if you already have your sql schema, created in mysql workbench, then you'd need to put that schema into laravel migrations using the schema builder.
there are tools that make this part easier:
http://www.laravelsd.com/ - kinda like mysql workbench, with an export possibility to laravel migration code
https://github.com/XCMer/larry-four-generator writes existing databases to laravel migration code
Another option is to use our tool Skipper (https://www.skipper18.com) We introduced Laravel support a month ago and now, in a beta phase, it is free for Laraver users.
Skipper allows you to import your MySQL Workbench project directly (or it is possible to import existing database too) and then export migrations and object files from Skipper to your Laravel project.
The benefit of this solution is that you can maintain your ORM schema directly in Skipper and continuously update model object files and create new migrations automatically from the application without the necessity to write any code manually.
If you want to try it, you can download it here https://www.skipper18.com/en/download, and in the initial application license screen select "Laravel Beta license".
I have a problem while working with SQLite database connection model in laravel 4.
After create schemas and run migrate:install, migrate, (db:seed) everything works perfectly. But if I delete the sqlite file for some reason, I am not able to recreate the file. migrate:install and migrate also run without any warnings but the app does not create the file. What am I doing wrong?
Laravel is not responsible for creating database files, they should exist when it tries to connect to them, but... PDO_SQLITE should create the database if it doesn't exists. Then, if it is not creating, you should check your folder permissions and webserver log files.
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.
I have a local instance of a database that I recently created using DbContext.Database.Create(), so the __MigrationHistory table exists with an InitalCreate entry that matches the code at the moment.
Some code-based migrations exist in the Migrations folder, however. These will be run in our development and staging environments to bring those databases in line with the code. I don't need to apply them locally, however, since I created the database using the current code.
I now need to make a change to the model and create the corresponding migration. But when I run Add-Migration TestMigration, I get the following error
Unable to generate an explicit migration because the following explicit
migrations are pending:
[201203271113060_AddTableX,
201203290856574_AlterColumnY]
Apply the pending explicit migrations before attempting to generate
a new explicit migration.
What should I do in this case? I can't point the Add-Migration tool at another environment because it's not guaranteed that version matches what I have locally. I want a migration that matches only the changes I've made.
It seems I have a few options but none are ideal:
Delete the other migrations from the Migrations folder, run the Add-Migration command, upgrade the database, then restore the old migrations. This is simple but seems a bit hackish.
Revert to the version of the model in source control that the first migration was applied to, then build this and use it to create the database. Then get the latest version, apply all the migrations, then I'm ready to add my migration. This seems like a lot of effort!
Create the migration manually.
Does anyone have any suggestions about how to manage this?
We are planning to use a variant of your Option #1...
Our Standard Operating Procedure is to generate a SQL script for each migration (using the -script option of update-database), in order to have SQL scripts to be applied to end-user "production" databases by InstallShield (we plan to use EF update-database only for developer databases).
Thus, we have both the Migration .cs files and the corresponding .sql files for all migrations in our Migrations folder.
So rather than deleting the migrations from the Migrations folder (as you proposed in #1), we use SQL Mgmt Studio to manually apply just the parts of the .sql files that do the inserts into _MigrationHistory.
That brings the _MigrationHistory of the local database up-to-date with the changes that are already incorporated into that database.
But it's a kludge, and we're still looking for a better solution.
DadCat
What I've found works best is very simple: don't use DbContext.Database.Create() once you've enabled migrations. If you want to programmatically create a new database, use the migrations API instead.
var migrator = new DbMigrator(new Configuration());
migrator.Update();
Then you've got the full migration history and adding further migrations works just as expected.
You either need to run "update-database" from the package manager console to push your changes to the database OR you can delete the pending migration file ([201203271113060_AddTableX]) from your Migrations folder and then re-run "add-migration" to create a brand new migration based off of your edits.
I have encountered the same problem.
If you run
Update-database
and then run
Add-Migration YourMigrationName
This solves the problem
simply exclude the old migration file from the solution files.