views:

2785

answers:

3

I have a table that has a primary key that's an INT... I have another table, that has a foreignkey relationship to that first table, but it's a NULLABLE INT.

This is perfectly ok, and 100% acceptable to SQL... however LINQ to SQL is complaining about mismatched types ("int to Nullable[int]").

Error Message: Cannot create an association "Store_People". Properties do not have matching types: "PersonID", "ID".

How do I solve this so that the designer stops yelling at a 100% correct usage of SQL?

+1  A: 

I have precisely that situation in a DBML now, and it is working fine.

Primary Key

  • Nullable - False
  • Primary Key - True
  • Server Data type - int NOT NULL IDENTITY
  • Type - int (System.Int32)

Foreign Key

  • Nullable - Trure
  • Primary Key - False
  • Server Data type - Int
  • Type - int (System.Int32) (actually defined as Nullable in the context.designer.cs file)
James Curran
Yeah, me too... scratching my head why it's not working for him.
GalacticCowboy
+2  A: 
GalacticCowboy
Wow... linking a thumbnail in SO is needlessly complicated...
GalacticCowboy
Thanks for your help... I found the problem.
Timothy Khouri
+3  A: 
Timothy Khouri
Not a bug, you were just associating them the wrong way round.
Garry Shutler
Effectively what you were trying to do, it sounds like, was set the dependent table as the parent and the table that *defined* the foreign key as the child - i.e., the relationship would work the opposite of your intent. FWIW, SQL won't let you create a relationship like this either.
GalacticCowboy
SQL will absolutely let you create a nullable foreign key to a non-nullable primary key. I don't think this solution works as well as he thinks it does either. You end up with a single object coming back, whereas having the association the other way around would give a LIST of objects back.
Telos