Otis wrote:
Please use terminology which is not ambiguous: Unique Key, is that a unique constraint next to a primary key? or is that a primary key? Or is it a unique index?
If it's a unique constraint next to a primary key (so other fields form the primary key), the FK points to a UC, not to a PK. FKs pointing to a UC aren't supported. Hence our question.
Sorry if I was not very clear in my description.
First of all, in my table I have a column called live_page_translation_id which is not a primary key - is just an int column. This column is also a UNIQUE KEY (not UNIQUE INDEX). This column is a foreign key to another table - linked to a primary key not to a UC.
So as a short structure I have like this:
page_translation (table)
id - int - PK
page_name - nvarchar(200)
page_tanslation_flow (table)
id - int - PK
live_page_translation_id - int - FK to page_translation (id) - UK (UK_page_translation_flow_live)
... other columns....
So, this makes LLBL creates the relation between page_translation_flow and page_translation as being a 1:1 relation (which is perfectly normal and great) but the UK_page_translation_flow_live is not listed as unique key in the designer and also is not visible by the template system (lpt). If I'm trying to add it manually in the designer, then the templating system acts normally but on the next refresh I'm loosing the UK with the following message:
The unique constraint 'UkPageTranslationFlowLive' has been removed from entity 'Entities.PageTranslationFlow' because its underling unique constraint couldn't be found in the refreshed relational model data or it's now a unique constraint for a 1:1 relationship.
Again, please, accept my apologize if I wasn't very clear.
Evdin