I'm using 3.0 Final.

I have a View in which I designated a "primary key" in the designer so that I could establish a relationship between it and an Entity. The relationship works great until I attempt to refresh the model to bring in any changes from the database. Once I do that I receive the results below and the manual relationship is removed.

The relationship 'db.View - db.Entity (1:1)' has been removed because its underlying foreign key constraint wasn't found in the refreshed relational model data.

How can I specify to always maintain this manually configured relationship even though it of course does not exist in the database?

How did you designate the PrimaryKey against the View...?

And did you sync the changes back to the database once you had made the change...?

Matt

tmpcl wrote:

I'm using 3.0 Final.

I have a View in which I designated a "primary key" in the designer so that I could establish a relationship between it and an Entity. The relationship works great until I attempt to refresh the model to bring in any changes from the database. Once I do that I receive the results below and the manual relationship is removed.

The relationship 'db.View - db.Entity (1:1)' has been removed because its underlying foreign key constraint wasn't found in the refreshed relational model data.

How can I specify to always maintain this manually configured relationship even though it of course does not exist in the database?

I just ran into the same issue. In "Preferences" under the "Catalog Refresher" category set "RelationshipsFollowDBForeignKeyConstraints" to false.

The will preserve any relationship that were manually created in the designer. The only bad thing about this is you now have to manually add any new relationship that was created in your database. I think there needs to be a 3rd option (still sync the automatic relationships but keep the manual ones).

Yes, we know this limitation and it's one of the first features we're developing into 3.1: 'model only relationships' (also for PK's and UC's).

Thanks for the feedback Frans. I will look forward to the 3.1 release and for now to continue to re-add the relationship after I refresh the model.

By the way, has anyone else reported about the designer automatically removing the s from status in entity mapping?

ApplicationStatus table becomes ApplicationStatu entity

I love all of the new features I've used in 3.0 so far. Great work!

tmpcl wrote:

By the way, has anyone else reported about the designer automatically removing the s from status in entity mapping?

ApplicationStatus table becomes ApplicationStatu entity

LLBLGen singularization routine assumes that table name is plural. To disable singularization follow these steps.

I don't want to disable singularization. I just wanted to point out that the singularization plugin is incorrectly removing the s from the singular stauts

Status is the singular form where statuses is plural.

tmpcl wrote:

I don't want to disable singularization. I just wanted to point out that the singularization plugin is incorrectly removing the s from the singular stauts

Status is the singular form where statuses is plural.

NamePluralToSingularConversion plugin uses Inflector, a class, which is used from the Castle Project (http://www.castleproject.org/), and which is licensed under the Apache 2.0 license.

So the set of rules applied doesn't contain an exception for "status". You can download source code from LLBLGen site (customer area) and add a regular expression rule for that specific word, recompile and copy the plugin assembly into LLBLGen's Plugin folder.

Hope that helps

Also, the system thinks that the names are plural as it does singularization. This means that if it sees 'status', it doesn't know the word as a plural exception (as it's a singular word!) and simply removes the s.

That's why disabling the singularization for databases which have singular names is better, as there's nothing to singularize as everything is already made singular.