As previously mentioned on here, one of the improvements v1.5 brings is the ability to define a PK on a view. This allows us to define a BO made up of multiple related tables, particularly the base-type/derived-type idiom, all within the database using SQL Server 'instead of' triggers on the view.

In essense, SF should treat such a view just like it was a normal table. But to get referential integrity support, SF needs to be able to assign the view a PK.

So now that I've just installed v1.5, I am apparently missing where in the DDT I would do that. It must be so obvious that I'm just looking in the wrong place...

Thanks!

Ah, the functionality was moved to the Business Object Mapper.  After you choose the view to which the business object gets its mapping information, you can go to the "advanced" options under the business object's properties and check the override primary key box, then click the "..." button and choose the fields that should be the primary key on the business object.

Okay...but if I can't define the view's PK in DDT, how do I define the relationships the view will have with the other tables, etc.?

That is the nice thing about the framework.  You can define the relationships within the business objects themselves.  The relationships defined on the BOs do not have to actually exist on the server.

Wouldn't referential integrity rules be required if the View was being used to insert or update values? I'm probably missing something.

SQL Server 2005 will not let you define foreign keys from a view to other objects.  You can define indexes on a properly configured view, but not relationships and not primary keys, just regular indexes.  The PK definition within the BOMapper allows the BOMapper to specify the primary key when building the partial class for the business object.  This allows the business object to properly create the dynamic SQL at runtime that will be used to "insert" or "update" the view.  Without a primary key definition, an update from the BO to the database would fail because the WHERE clause of the update would not be able to specify only a single row.

I told you that I might be missing something Thanks for clarifying that for me.