We have a EF model of a DB2 database.
Is it possible to use this model to generate a SQL Server database? And then switch between using
DB2 and SQL Server?
We were thinking that the developers could develop against a local SQL Server database.
We use EF 4.1.
There can be problems with the field types, if you define them for yourself.
I have been doing such a thing with Sql-Oracle, and in the end, we where creating custom Attributes, like [VarcharAttribute] and configured the entities to use the correct typename in the OnModelBuilder function.
This might not work :
[Column(TypeName="varchar")]
public string Data{get;set;}
because for Oracle it should look like this :
[Column(TypeName="VARCHAR2")]
public string Data{get;set;}
Also there can be other problems, for example in the sql-oracle merge a table name was over 30 characters, and it worked in sql, but didn't work in oracle, because the table name was limited to 30 characters.
But after you fix these problems, then it will work. At the end we were able to set the provider from config file.
So yes, it is possible, if you take care of the database differences
Old question but...
You can't use migrations with IBM DB2 EF Provider.
About EF 6 (without migration) for DB2, now is supported by IBM
You can find official nuget package for EF support here
http://www.nuget.org/packages/EntityFramework.IBM.DB2/
but it does not support migrations.
If you need migration you can use also this package (in addition to previous package)
https://www.nuget.org/packages/System.Data.DB2.EntityFramework.Migrations/
You can find more info here
https://db2ef6migrations.codeplex.com/
Related
I maintain a Windows based application backed by SQL Server DB so there is a set of SQL entities, like tables, views. With time I add new features and fix bugs so schema of the tables and views changes. Once I need to deploy a new version of the application I deploy the DB part by relying on DacPac/DacFx which automatically generates a difference between already deployed DB and the supplied DacPac so the already deployed DB is altered to match the DacPac's content. This way I don't have to write a code which compares 2 schemas and then generates a difference - DacFx does that for me.
That works well but now I need to expand the application so it also supports SQLite DB, I will for sure have to create a new application layer working with SQLite which is doable but one place I need help with is being able to create and maintain SQLite DB schema in the same way I do for SQL Server with DacPac/DacFx so a difference in schemas is computed and applied. While doing that I ideally want do write the SQL schema once so it could be applied to SQL Server as well as SQLite. Ideally, I need to generate SQLite schema based on the schema specific to SQL Server.
I looked into sqldiff which is capable of generating difference between 2 SQLIte DBs and thought I could:
use a technique from here to migrate SQL Server schema to SQLite
generate a temporary SQLite DB based on the generated above schema
compare the above deployed temporary DB to an existing SQLite DB by using the sqldiff and finally apply the difference to the target SQLite DB
but the sqldiff, as stated in the Limitations section:
The sqldiff utility is not designed to support schema migrations
In addition it has limitations around views:
The sqldiff.exe utility does not (currently) display differences in
TRIGGERs or VIEWs.
So I interpret that like that tool could probably be used for some migration cases but it is not really recommended.
How do you suggest generating and applying the schema differences?
I'm also interested to know how others solve the task of incrementally updating schema of their SQLite DB even if I take SQL Server completely out of equation and would instead maintain SQLite schema, in the source code, only. Does everyone create their own schema comparing tools instead of using something similar like DacFx in SQL Server world?
So I'm working on an ASP.NET project for university. We have to upload our code to a server running IIS and SQL Server 2008. I've written my project using MVC Code-First EF. I understand that the Entity Framework system needs permission to create the database to work properly (you can't just give it an empty database and let it fill it with data). This has created a problem for me since I do not have database creation privileges on the shared SQL Server. Is there any way around this?
As you don't have permissions, it sounds like you'd need to get a DBA to create your database on the server you are trying to deploy to - this could be done from either a database creation script or from a database backup of the db on your dev machine. You can then instruct EF code first not to try to create / update the database automatically by adding this line to your global.asax (or indeed anywhere before you first access the database)
Database.SetInitializer<YourContextType>(null);
You can use an existing database, rather than let EF create one for you. I have done this myself, but admittedly only when using EF Migrations. Otherwise, you run into trouble with missing table exceptions and what not.
When using migrations, just point your connection string to your empty database, create an initial migration to populate the database with your schema and then update the database itself.
See this answer: How do I create a migration for an existing database in EntityFramework 4.3?
.. which include this nice link to getting started with EF Migrations: http://thedatafarm.com/blog/data-access/using-ef-migrations-with-an-existing-database/
All this is available through Nuget, and if you have access to Pluralsight content, I can highly recommend Julie Lerman's video on the topic.
If you don't want to use Migrations, you can still use Code First if you just create the database objects manually using SMMS, but obviously you have the manual work of keeping your model and the database in sync.
I've been working on an ASP.NET Entity Framework 4.3 Code-First application, which governs the model for the parts of the database it cares about. As this database will be used by multiple other applications (some not using ef so can't import models) the idea was to create the base database with my application. After this the DBA could add other fields and tables not used by my application as necessary.
The problem arrises when implementing changes to the model in my application. Our idea was to use the new Migrations feature of EF 4.3 to create scripts (-script feature) while pointing to our local machine dev db (SQLCompact), which will then be passed to the DBA for migrating the actual dev database (MS SQL 2008) that all of the other applications use.
This has been causing problems though, as when I began testing (pointing to SQL server) the application couldn't read any foreign key relationships, giving errors that these columns don't exist. I'm wondering if this is caused by the differences in translation of SQL Compact and SQL Server (EF to SQL), or some other problem is the cause.
Should I be bothering with EF migrations for this type of 1-DB multiple App environment at all? Do I need to run all my migrations directly against the SQL Server? Is there an entirely different change strategy I should be using? Any help or guidance would be appreciated.
Well, you could try installing SQL Server Express locally instead of using compact. That should get rid of any differences there might be between compact and standard.
We are trying to build a data access layer for using both Oracle and SQL Server (not at the same time).
We use EF Model-first for creating the model and the create the SQL scripts for building the database. Our first thought was to create 2 EDMX files, one for each type, and use the appropriate one depending on the client's need. We are using the Oracle and SQL Server database generation workflow and DDL generation template to create the scripts for each database.
Our main problem is when the database schema changes we do not want to drop and recreate the DB but only create the migration scripts to update the DB base on our model (clients have many data that will be lost).
We use EF power pack for extracting the migration scripts for SQL Server but there is nothing like it for Oracle.
We want help to find a good data layer (1 EDMX for both Oracle and SQL Server if it's possible and not complicated) and a good way to generate database changes from our model to update existing client DBs in case of a new application release
We found this as a starting point
http://msdn.microsoft.com/en-us/data/ff830362 but there is not mention for Oracle support.
We have tried code-first and EF Migrations but Oracle failed us again on the DB creation and migration.
Any recommendation on how we can accomplish this?
Thank You
There is no way to have single EDMX for both SQL Server and Oracle. EDMX consists of three parts CSDL (entity definition), SSDL (database definition), MSL (mapping between those definitions). SSDL must always target concrete database so you need at least separate SSDL for Oracle and SQL Server and if you are lucky you will not need separate MSL as well (mapping must be exactly same which will probably not happen if you are using any tool to generate the database).
So you always need at least part of EDMX file for second DB and manually maintain it.
If you need DB migration supporting Oracle you must look for tool from Oracle (or third party). For example RedGate offers tools supporting schema migration for both SQL Server and Oracle.
Visual Studion Premium and Ultimate edition also offers tools for comparing database schemas. It by default supports only SQL Server but Toad Extensions should add support for Oracle as well.
Once you have any of these tools you just need to compare schema deployed on customer server with your new schema and the tool should create migration script for you.
The best article I found on this topic is from Paul Reynolds Blog.
Try to go through from part 5 to part 9.
There are so many gotchas about Oracle mentioned there... is very helpful!
I'm currently working on a SOA project where at some locations it would make sense for the service to use a lightweight database (SQL CE 4.0) while at other locations a more robust database is desirable (SQL Express right now, but possibly scaling up to larger editions).
Even though the model and table structure is identical for both SQL Express and SQL CE, I can't figure out how to get Entity Framework to use the same EDMX to work with both databases. The conceptual model is identical for both, and the only difference in the storage model is the provider name that is used to access to the database.
Am I missing something, or do I need to keep two basically identical models around, one for each database.
I'm using .NET 4.0, Entity Framework and VS 2010 SP1
Unfortunatelly I think you have to create two separate SSDLs with different provider and manually keep them in sync (this can be actually done by some post build script wich will copy ssdl file and replace a provider). Still you have to be sure that table structures are same:
same table names
same column names
same data types
The last point can be critical because as I know SQL CE doesn't support some types common in SQL Server. For example I think navarchar(max) and nvarbinary(max) is not supported in SQL CE.
To force EF to create SSDL file instead of including it as a resource change Metadata Artifcat Processing (in properties of EDMX designer) to Copy to output directory and modify connection string. Here is a related article.
You can do this if you don't mind switching to Code First. Gallery Server Pro 3.0 uses Code First to target either SQL CE or SQL Server, depending on the user's preference. There is a single code base with the only difference being the connection string in web.config.
It's an open source project so you can see how it's done in the code.