EFDAL: bug in joins involving multiple columns?

Feb 6, 2012 at 5:36 AM

I'm pretty sure there's a bug in the table generation code for inherited tables when the primary key is composite. For example:

Parent_Table
Col1 nvarchar(50) not null
Col2 nvarchar(50) not null

where Col1 &  Col2 form a composite primary key

The generated sql in the derived tables uses the following syntax:

parent INNER JOIN child ON parent parent.col1 = child.col1, parent.col2 = child.col2

(I've left out the brackets and other stuff for clarity)

The generated code should look like this:

  parent INNER JOIN child ON parent.col1 = child.col1 AND parent.col2 = child.col2

You can work around the bug by doing a text replace on that erroneous comma, but it's a little tedious in the the files get recreated every time you do a generate, so you have to go back and redo the text replace. Another workaround would be to get rid of the composite primary key and store the component parts in another table that includes an IDENTITY field as a primary key.

- Mark

Coordinator
Feb 13, 2012 at 6:49 PM

Please tell me where you see this? In the installer scripts? In the NHDAL gen code? EFDAL? I am having a hard time finding it.

Feb 17, 2012 at 3:02 AM

It involves the scripts in the Install assembly, in the Stored Procedures/Generated/Objects folder. Specifically, any script where the table has joins using complex keys to another table. Or maybe it's just when the inheritance "key" is complex. It's been a while...

- Mark