Using SqlEntityConnection, mapping of CLR type to EDM type is ambiguous

Question

I'm trying to rewrite a pretty simple app, from C# to F#, now using the SqlEntityConnection type provider, and I'm running into an EF issue: "the Mapping of CLR type to EDM type is ambiguous," which can occur from opening two SqlEntityConnections that each have a table with the same name.

In this case, however, it's because EF, through the type provider, is apparently mapping a system table. The actual error references the dtproperties table --

{"Schema specified is not valid. Errors: \r\nThe mapping of CLR type to EDM type is ambiguous because multiple CLR types match the EDM type 'dtproperties'. Previously found CLR type 'SqlEntityConnection2.dtproperties', newly found CLR type 'SqlEntityConnection1.dtproperties'."}

How can I change this table being mapped? Thanks.

(This isn't a problem in the original C# version, which also uses EF.)

• Joel Mueller: I don't know of a way to filter which tables the type provider generates types for. If you must have two SqlEntityConnection-derived types in your project, I would first try putting them in different namespaces. If that doesn't help, then I guess you can always delete the "dtproperties" tables...
• rachel: @JoelMueller Thanks, I'd tried the different namespaces thing, but it doesn't seem to make a difference. And unfortunately, I can't delete dtproperties without angering DBAs. :(
• Joel Mueller: Could you maybe connect to the database with the credentials of a user who doesn't have permission to see "dtproperties"?
• rachel: Well, boo. The accounts I can access apparently have permission to see it. Not helpful, but also an issue: I noticed that when both type providers are in the same actual file, there's an obj. ref not set to an instance of obj error. shrug?
• rachel: To come back to this question: I never was able to find a proper answer, but as a work-around, I switched to using the SQLDataConnection provider, and was able to finish the project. For one database, I also needed to set StoredProcedures=false, which eliminated many, many schema errors. Hope this at least helps out someone else. :)

Answer 1

It is because you are using POCO and have two types with the same type name. EF ignores namespaces and therefore two types with the same name but different namespaces are ambiguous for EF. ( http://entityframework.codeplex.com/workitem/483 )

• Joel Mueller: The SqlEntityConnection is strictly database-first. No chance there's POCO's involved.
• rachel: Right, I'm aware of the issue. But in this case, EF (through the type provider) is mapping a system table, and that's what's causing the error. How do I stop mapping this table?
• Pawel: @JoelMueller - This is not true. The default code generator in VS2010 would generate EntityObject but in VS2012 it will generated POCO. Also even for VS2010 you could use POCO T4 templates that would generate POCO types for Database First.
• Pawel: @rachel - I haven't used F# and SqlEntityConnection. How do you create the edmx file and the classes? If you don't expect the dtproperties type to be there it seems that the tool used to create the edmx file (and types) did not let you pick what tables you wanted. You can try using VS2012 and unselect tables you don't want when creating a model from the database.
• rachel: @Pawel Basically, you don't need the edmx file and the classes, which is why I'm a little lost. (See msdn.microsoft.com/en-us/library/hh361035.aspx) I keep hoping for a flag or something? Pretty much the only code needed is: type private EntityConnection = SqlEntityConnection<ConnectionStringName="CustomerDB"> then let context = EntityConnection.GetDataContext()