471,356 Members | 1,519 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 471,356 software developers and data experts.

EF EDM Designer is ticking me off... and other EF questions

#1
----
Why does VS2008 "forget" how to open EDMX files?? After opening and
closing the file a few times, double clicking on the EDMX file just ends
up expanding/collapsing the contents (the .Designer.cs file), but
doesn't actually open the file in the designer. Right-clicking the file
and clicking "Open" does absolutely nothing. Right-clicking the file
and selecting "Open With..." gives me the option to open with the
ADO.NET Entity Data Model Designer (which is default) but when I select
that, it doesn't do anything at all either. I have to close VS2008 and
reopen it to get it to work again... Anyone else seeing this?

#2
----
I'm also a bit frustrated that when I remove an entity from the design
surface, there seems to be no way to get it back other than to edit the
EDMX, remove all references to the table, and then refresh from the
database. (Yeah I guess I could manually edit it in, but that's error
prone and shouldn't be necessary.) Am I missing something?

#3
----
On a lighter note, I'm also having issues with how it handles inherited
classes, but this is probably just me needing some help in
understanding. I want to have a class derived from a base class... my
table structure looks like this:

BaseItem DerivedItem
--------- ------------
BaseItemId uniqueidentifier, PK ---- DerivedItemId uniqueidentifier, PK
BaseItemField varchar(50) DerivedItemField int

where the "----" represents a SQL relation between the two fields.

First, when I import these two tables, EDMD imports them as a relation..
ok I can understand that, although I think that default behavior if two
PKs are used should be to assume that you want inheritance. Anyway, so
I delete the relation and specify on DerivedItem entity that the base
class is BaseItem. When I do this, it sets the EntityKey property on
the DerivedItemId field to false. ummm ok. The model saves fine, but
when I Validate, I get an error... Error 3024: Problem in Mapping
Fragment starting at line 177: Must specify mapping for all key
properties (BaseItem.BaseItemId) of the EntitySet BaseItem. I've
googled this and there's a lot of talk about it, but not much of a clear
solution that I can see.

Actually, I know how to fix this... if the base class and the derived
class have the same name for the primary key, then I can work around
this issue by deleting the (derived) primary key from the derived
entity, then remapping the database column back to the (inherited)
primary key.

So my first question is... Why can't I do the same thing when the
derived class and the base class have differently named primary keys?

My second question in this scenario is... when I specify the base
entity on the derived entity, how does EDMD know that it is the
BaseItemId - DerivedItemId link that drives the inheritance? Is it just
using the previous relation? What happens if there were alternate
relations between the two tables? For example, in my real database, I
want to have an "Employee" that derives from "Person". But I also want
employee to have a relation to "Person" thru a relation that represents
the employee's emergency contact... Maybe I'm getting into scenarios
that the designer isn't up to par with yet??

-mdb
Aug 20 '08 #1
5 2024
Hi Michael. I am having same issues as #1 and #2. Looks like it is SP1v2
time.

"Michael Bray" <mb***@dontemailme.comwrote in message
news:Xn*****************@207.46.248.16...
#1
----
Why does VS2008 "forget" how to open EDMX files?? After opening and
closing the file a few times, double clicking on the EDMX file just ends
up expanding/collapsing the contents (the .Designer.cs file), but
doesn't actually open the file in the designer. Right-clicking the file
and clicking "Open" does absolutely nothing. Right-clicking the file
and selecting "Open With..." gives me the option to open with the
ADO.NET Entity Data Model Designer (which is default) but when I select
that, it doesn't do anything at all either. I have to close VS2008 and
reopen it to get it to work again... Anyone else seeing this?

#2
...

Aug 21 '08 #2
Michael Bray wrote:
#3
----
On a lighter note, I'm also having issues with how it handles inherited
classes, but this is probably just me needing some help in
understanding. I want to have a class derived from a base class... my
table structure looks like this:

BaseItem DerivedItem
--------- ------------
BaseItemId uniqueidentifier, PK ---- DerivedItemId uniqueidentifier, PK
BaseItemField varchar(50) DerivedItemField int

where the "----" represents a SQL relation between the two fields.

First, when I import these two tables, EDMD imports them as a relation..
ok I can understand that, although I think that default behavior if two
PKs are used should be to assume that you want inheritance. Anyway, so
I delete the relation and specify on DerivedItem entity that the base
class is BaseItem. When I do this, it sets the EntityKey property on
the DerivedItemId field to false. ummm ok. The model saves fine, but
when I Validate, I get an error... Error 3024: Problem in Mapping
Fragment starting at line 177: Must specify mapping for all key
properties (BaseItem.BaseItemId) of the EntitySet BaseItem. I've
googled this and there's a lot of talk about it, but not much of a clear
solution that I can see.
Heh, yes I've seen this too when I tested the EF designer with our
inheritance test db.

It's really silly that they run into this error as Nijssen/Halpin
described clearly back in 1989 in their book "Conceptual Schema and
Relational Database Design" how to formulate tables which represent an
entity inheritance hierarchy: they gave a couple of options, one being
the one you defined above.

So reverse engineering the relational model back to a model at the
entities abstraction level (similar to NIAM/ORM), is simply analysing
the model if you see these kind of relations and if so, use them for an
inheritance hierarchy. LLBLGen Pro does this automatically and I was
surprised the EF designer not only wasn't able to detect them, but
actually ran into a problem where it made life very hard for the user
who simply wanted to define the inheritance hierarchy the way it was
meant (i.e. the inheritance hierarchy which LEAD to the table setup as
you described!)

Even more ironic is that prof. Halpin was a MS employee for quite a
while. :)
Actually, I know how to fix this... if the base class and the derived
class have the same name for the primary key, then I can work around
this issue by deleting the (derived) primary key from the derived
entity, then remapping the database column back to the (inherited)
primary key.

So my first question is... Why can't I do the same thing when the
derived class and the base class have differently named primary keys?
I think they've overlooked this possibility of overriding fields
through different names. Which is odd as they don't even have the
concept of a FK field in the entity.
>
My second question in this scenario is... when I specify the base
entity on the derived entity, how does EDMD know that it is the
BaseItemId - DerivedItemId link that drives the inheritance? Is it just
using the previous relation? What happens if there were alternate
relations between the two tables? For example, in my real database, I
want to have an "Employee" that derives from "Person". But I also want
employee to have a relation to "Person" thru a relation that represents
the employee's emergency contact... Maybe I'm getting into scenarios
that the designer isn't up to par with yet??
I think that they'll pick the PK-PK relation as that's the only
relationship which can be used for inheritance. There's no other way.

FB

--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Aug 21 '08 #3
I got some joy on these from Pablo:

"Issue 1: if the table is already "known" to the designer, then you don't
need to import it again. If you delete it from your conceptual model you can
re-add it by creating a new entity and mapping it to the underlying table
(in the mapping designer the table will still show up). The "update from
database" thing is usually needed when you actually changed something in the
database, or want to add something that you didn't add originally.

Issue 2: yeah, that's our bad (i.e. DateTimeOffset not supported). It's not
that we didn't catch it, actually. Because of timing issues we couldn't get
support for this data type in Astoria v1.

Issue 3: (Not able to open Model) I've seen this too in my box, but couldn't
reproduce it reliable. Do you happen to have the Silverlight tools
installed? I have a "weaking founded" theory that these two are not
interacting well..."

Aug 24 '08 #4
"William Stacey [C# MVP]" <wi************@gmail.comwrote in
news:CC**********************************@microsof t.com:
I got some joy on these from Pablo:
Who's Pablo? (Obviously I'm sure one of the EF designers, I just am
curious about the details.)
"Issue 1: if the table is already "known" to the designer, then you
don't need to import it again. If you delete it from your conceptual
model you can re-add it by creating a new entity and mapping it to the
underlying table (in the mapping designer the table will still show
up). The "update from database" thing is usually needed when you
actually changed something in the database, or want to add something
that you didn't add originally.
I think I see what he means... the problem then is that I have to map
every single field manually, unless there is a way to do this automatically
that I'm not seeing. Actually, it will do some automatic mapping - but
only of the primary keys, it appears.
Issue 2: yeah, that's our bad (i.e. DateTimeOffset not supported).
It's not that we didn't catch it, actually. Because of timing issues
we couldn't get support for this data type in Astoria v1.
Ummm... I'm not quite sure what you are referring to here... it doesn't
seem to be an answer to any of MY questions. (Perhaps you confused my
questions with someone else's question??)
Issue 3: (Not able to open Model) I've seen this too in my box, but
couldn't reproduce it reliable. Do you happen to have the Silverlight
tools installed? I have a "weaking founded" theory that these two are
not interacting well..."
Not sure, really... I don't think so. I have so much stuff loaded on my
dev box that I can't keep track of it. I know I can run Silverlight stuff,
but I don't think I have any 'tools' loaded. Don't hold me to it, though.

I haven't been able to reproduce it reliably either, but it happens often
enough that it is really annoying.

-mdb
Aug 25 '08 #5
They are looking at changing the delete/add table behavior for V2. Until
then, you have to manually add entity and columns or delete the whole model
and add new.

"Michael Bray" <mb***@dontemailme.comwrote in message
news:Xn*****************@207.46.248.16...
"William Stacey [C# MVP]" <wi************@gmail.comwrote in
news:CC**********************************@microsof t.com:
>I got some joy on these from Pablo:

Who's Pablo? (Obviously I'm sure one of the EF designers, I just am
curious about the details.)
>"Issue 1: if the table is already "known" to the designer, then you
don't need to import it again. If you delete it from your conceptual
model you can re-add it by creating a new entity and mapping it to the
underlying table (in the mapping designer the table will still show
up). The "update from database" thing is usually needed when you
actually changed something in the database, or want to add something
that you didn't add originally.

I think I see what he means... the problem then is that I have to map
every single field manually, unless there is a way to do this
automatically
that I'm not seeing. Actually, it will do some automatic mapping - but
only of the primary keys, it appears.
>Issue 2: yeah, that's our bad (i.e. DateTimeOffset not supported).
It's not that we didn't catch it, actually. Because of timing issues
we couldn't get support for this data type in Astoria v1.

Ummm... I'm not quite sure what you are referring to here... it
doesn't
seem to be an answer to any of MY questions. (Perhaps you confused my
questions with someone else's question??)
>Issue 3: (Not able to open Model) I've seen this too in my box, but
couldn't reproduce it reliable. Do you happen to have the Silverlight
tools installed? I have a "weaking founded" theory that these two are
not interacting well..."

Not sure, really... I don't think so. I have so much stuff loaded on
my
dev box that I can't keep track of it. I know I can run Silverlight
stuff,
but I don't think I have any 'tools' loaded. Don't hold me to it, though.

I haven't been able to reproduce it reliably either, but it happens often
enough that it is really annoying.

-mdb
Sep 9 '08 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

8 posts views Thread by Metro Sauper | last post: by
9 posts views Thread by James Geurts | last post: by
1 post views Thread by Sebastian Sylvan | last post: by
3 posts views Thread by Chris Hayes | last post: by
2 posts views Thread by tom | last post: by
4 posts views Thread by Goran Djuranovic | last post: by
reply views Thread by XIAOLAOHU | last post: by

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.