Comments on: .Net 4.0 Beta 2 Entity Framework – Many To One and POCO / INSERT statement conflicted with the FOREIGN KEY constraint issue

By: Sean

Sean — Tue, 24 Aug 2010 14:05:10 +0000

Well I’ve heard such things in american movies and as we all know, american movies always paint a perfect picture of other cultures. So you sir, are in the wrong.

By: Jason

Jason — Tue, 24 Aug 2010 05:38:56 +0000

Dude, the English don’t say Zed for Zero. Us Australians and the English say ‘zero’ or ‘nought’, just as you do (if you say nought that is). We say ‘zed’ for the last letter of the alphabet. That shouldn’t be too hard to work out from the context. Just sayin’

By: Sean

Sean — Tue, 22 Dec 2009 16:59:00 +0000

Welcome to my world.

By: kdawg

kdawg — Tue, 22 Dec 2009 16:32:40 +0000

i’m still not sure how the ID gets properly updated correctly based on …After… instead of …Before… (and actually, I have no idea for sure if it was the source of my problem — it’s such a specific case with so many environment variables, it’s ridiculous), BUT i did notice that using …After… instead of …Before… forces the POCO to be a straight POCO, rather than using EF proxies for change tracking, if enabled.

Which makes sense, if you save after changes, then there should be no proxies to keep track of anything.

EF4 is really cool, but it’s required a fair amount of digging around and figuring things out on my own so far. then again, it is in beta2, so maybe i should lay off a bit… =)

thanks for the help, btw!

By: Sean

Sean — Tue, 22 Dec 2009 02:46:59 +0000

Pretty sure I tried DetectChangesBeforeSave in fact because it seems oddly logical. Sometimes I find Entity Framework like a Mac, do what you think it logical and then try the exact opposite.

By: kdawg

kdawg — Tue, 22 Dec 2009 00:00:23 +0000

it worked with AcceptAllChangesAfterSave option instead of DetectChangesBeforeSave? weird. i’m chasing down something similar, am curious to see if this fixes my issue.