I am using EF 5 and SQL Server 2005, Model First (sort of).
By sort of, I mean that I typically build my schema in the SQL Server designer, but import the schema into EF so I have a visual view. There is often round-tripping.
However, I noticed that when I try to generate the DB schema based on the EF model, it skips all of the NEWID() default values that I have assigned as default values to my Guid IDs, but it doesn't skip the identity fields of type int.
I found this post explaining the reasoning for this:
Entity Framework 4 and Default Values
However, it doesn't answer my question: How do I get Entity Framework to generate a SQL DDL database schema with default values of NEWID() for my uniqueidentifier types?
NOTE:
I don't care about how to set them from the POCO entities and so forth (there are plenty of posts describing that) - my concern is getting the SQL DDL generated right so I can seed the database without worrying about these values going missing.
Using Entity Framework Migrations, you can use the GUID column builder and its DefaultValueSql parameter. The value of that parameter can be the string "NEWID()". This should take care of proper DDL generation.
Next you should declare these properties as database-generated using attributes or the fluent model builder, so that EF ignores the values set in your POCOs (which will be null for new objects).
Related
I am trying to change the service based database in my project to SQLite. I am using EF database first approach but the EF does not generate every model from database. Eventhough foreign keys are set it does not generate the connections and also returns an error:
> Error 6005: The data type '' is currently not supported for the target Entity Framework version; the column 'Id' in the table 'main.Comments' was excluded.
It does so with every table that has an Id column (integer, primary key).
How can I fix this?
Thanks
in my database first application (Firebird), the primary keys are not set to identity by default !
how to fix that from the t4 template generation file ?
thanks and good day
Primary keys are not necessarily identity columns, and Firebird 2.5 and earlier doesn't have identity columns. Instead you simulate it with a trigger and a sequence/generator, but this isn't 'detectable' from a metadata perspective (or at least pretty hard to infer correctly). Identity columns will be introduced in Firebird 3.
For the entity framework client for Firebird to recognize the column as identity, you need to add a comment to the column (in the database!) with the text #PK_GEN#, like so:
comment on column yourtable.yourcolumn is '#PK_GEN#'
See also: Generated primary key in Entity Framework model from Firebird
Ì am currently working on a ASP NET MVC project. We use Entity Framework and follow the Database First approach. The database already exists.
The database has been created using the convention, that every table has a specified single primary key, even if it is a junction table.
Example :
Table User :
UserId (PK);
Username
Table UserRole :
UserRoleId (PK);
UserId (FK);
RoleId (FK)
Table Role :
RoleId (PK);
Rolename
As said, the database already exists and this convention is not discussable.
When I want to create an Entity Data Model in Visual Studio, I also have three Entities. But it would only make sense to have two Entities: User and Role. The UserRole Entity makes no sense.
Is there any possibility I can influence the way that Entity Framework maps my tables, so I can get rid of those relational (useless) entities?
Is there any possibility I can influence the way that Entity Framework
maps my tables, so I can get rid of those relational (useless)
entities?
No, you cannot force EF designer to do that. When using automatic tools you will always end with junction table mapped as a separate entity because it is not considered as junction table any more - it has special data (a separate key) which gives this entity new possibilities (for example relation between two entities can exist multiple times which is not possible with normal junction table).
The only way to avoid this is abandon tooling support and use either code mapping or manually write EDMX file and don't tell EF about that additional key. Instead let EF believe that there are only those two FKs forming composite PK as expected from junction table. Obviously if your database requires those special possibilities allowed by separate PK you cannot do this.
I am trying to create a record in the db that has a predefined primary key value. I know how to do this with sql, but I was wondering if EF can do this for me? Otherwise, I will have to create a stored proc for the inserts.
In case you have the StoreGeneratedPattern attribute set to "None" for your entity, the Entity Key value you specify for it will be passed to database.
In case this attribute is set either to "Identity" or to "Computed" there is no way to control what value will be set to this column in DB.
So, if you have an auto-incremented column in your database and the ADO.NET Entity Data Model wizard has set the StoreGeneratedPattern for you, you can manually change this attribute to "None" in the SSDL part of the model using XML Editor, and then enable IDENTITY_INSERT.
You can use the ObjectContext.ExecuteStoreCommand method if you are using EF4 or use the ObjectContext.Connection.StoreConnection property to execute a SQL command SET IDENTITY_INSERT <Your_Table> ON (both in EF1 and EF v4).
I'm evaluating using EF against an existing schema - the problem is that I can't work out how to set up associations between tables where the foreign key is NOT the primary key of the master table.
As an example, a foo may have many bars as defined like this (forgive the pseudocode):
table foo {
int foo\_id pk,
char(10) foo\_code,
...
}
table foobar {
int bar\_id pk,
char(10) bar\_foo\_code fk(foo.foo\_code),
...
}
What am I missing to be able to create the foo_foobar association, and hence a Bars navigation property on the Foo entity?
Linq to entities doesn't support Foreign Keys which don't point to the primary key of a table (see log message 3). Linq to entities will treat it as a normal field on a table. You won't be able to navigate to the entity it's linked to.
If you have an existing schema i'd recommend using the edm generator as this will create the EMDX file, code behind and even the view code (which can be very large). If your existing scheme is quite large Check out this post, which explains how to deal with large schemas.
When you run the EDM Generator you'll find out all the things that are not supported.
Looking at a previous EDMGen2.exe log we got the following types of messages back:
The data type 'sql_variant' is not
supported, the column 'ColumnName'
in table 'TableName' was
excluded.
The table/view 'tableName' does not
have a primary key defined. The key
has been inferred and the definition
was created as a read-only table/view
The relationship 'RelationshipName'
has columns that are not part of
the key of the table on the
primary side of the relationship
which is not supported, the
relationship was excluded.
We've also found that the Linq project actually crashed Visual Studio quite alot as the code file produced by EDM was well over 80 mb.