I loaded a v4.2 project in v5 and noticed a whole lot of 'DZ0025: For the database with driver 'SQL Server 2000-2016/Express Driver (SqlClient)', the relationship xxxyyy This conflicts with the setting 'RelationshipsFollowDBForeignKeyConstraints' which is set to true and the containing schema is synced with an external database for '

These were all for relationships from an entity mapped to a view, most of the relationships were set as 'Is Model Only' but the ones that weren't gave me this error. I can easily change them to 'Is Model Only' but, it seems to me, a redundant setting as all relationships on a view-mapped entity could only ever be 'Is Model Only'. (BTW there is a hyphen in the context menu but not in the relationship editor i.e. Model-Only )

Is there any case where this setting (and its warning) is useful for a view-mapped entity, maybe when its mapped to a view in one relational model but to a table in another?

I ask because I wasted some time on this, trying to work out why the relationship wasn't showing in the catalog, before I remembered the entity was mapped on to a view.

Hmm, something is off. The thing is: it checks first whether the fk side is a table. If not, it skips the relationship: it checks if the target in the fk side's mapping is a DBTable object. If not, it never checks for a missing FK.

This means it can't give the error on relationships where the FK side is a view. FK constraints are defined on the Fk side so checking whether that's a table or not is enough.

Could you check the FK side is indeed the view or that the PK side is the view?

Otis wrote:

Could you check the FK side is indeed the view or that the PK side is the view?

The View-mapped Entity (WorkRequest) is the PK side in the 11 errors that came up. The underlying table (qaoc_Work_Request) has 10 FKs of its own and 18 FKs from other tables referencing it. I initially thought some relationships where missing from the DB, when I saw they were there I tried to work why they weren't getting into the LLBL catalog, only when I remembered that WorkRequest was mapped to a view and therefore the table wasn't in the catalog did I work out why.

At one point early on, the WorkRequest entity was mapped directly to the qaoc_Work_Request table but now it goes through a view, so I guess most of those relationships were created when it was mapped to the table.

I think you're right: if either side is a view, there will never be an FK constraint, so the check is then moot. We'll adjust the check so it will only give the warning if both sides of the relationship are mapped on a table, not just the FK side.

You can safely ignore this error.

Fixed in v5.0.5 (hotfix build released later today)

Otis wrote:

Fixed in v5.0.5 (hotfix build released later today)

Thanks but we haven't bought an upgrade to v5 yet so I will have to take your word for it.

TomDog wrote:

Otis wrote:

Fixed in v5.0.5 (hotfix build released later today)

Thanks but we haven't bought an upgrade to v5 yet so I will have to take your word for it.

What we did was added a check to see if both sides of the relationship is mapped to a table. If that's not the case (one side or both sides are mapped to a view), the relationship is skipped. We created a project which contains all situations and added an automated test to our designer integration tests and this succeeds. The issue wasn't complex.