Hi

I've tried to create a 1 to 1 relationship between 2 entities, and the modeller lets me do this but I get the error:

DataAccess.Persistence.Invoicing.csdl(201,6) : error 0113: Multiplicity is not valid in Role 'ABillingProcessData' in relationship 'ABillingDocumentSource_ProcessData_ABillingProcessData_DocumentSource'. Because the Dependent Role properties are not the key properties, the upper bound of the multiplicity of the Dependent Role must be *..

at run time (and also in VS when compiling the edmx)

If I set it to be a 1 to many then it works fine.

Various posts on forums indicate that 1 to 1's require an extra hint to be given to the model (via fluent!) to tell it which is the primary side of the relationship. this is not possible in LLBLGEN or in the VS EF modeler.

eg http://stackoverflow.com/questions/18724964/entity-framework-1-to-1-relationship-using-code-first-how

Have you come accross this issue, and do you have any suggestions as obviously a 1 to many is a poor substitute for a 1 to 1. Note that I have "Emit FK fields" as True! which seems to affect EF for some reason (according to some articles)

Please post more information about the issue (Ref: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=7717 ). Mainly:

• LLBLGen build version.
• Target framework (EF1, EF2, EF4, etc.)
• TemplateSet that you are using to generate code.

I assume the 1:1 is on FK/UC combination? (which should be reported as an error in the designer, as EF doesn't support these)

Hi

Llblgen pro 4.1 Entity framework 6.1 Standard templates

Whats a UC?

It is on a FK and PK. One side could be made a 0..1, but that doesn't seem to help either.

A lot of the articles say it isnt easy model first without modifyibg tge edmx by hand ir using some fluent with code first.

fpdave100 wrote:

Hi

Llblgen pro 4.1 Entity framework 6.1 Standard templates

Whats a UC?

Unique constraint, something EF doesn't support.

It is on a FK and PK. One side could be made a 0..1, but that doesn't seem to help either.

A lot of the articles say it isnt easy model first without modifyibg tge edmx by hand ir using some fluent with code first.

The FK side is that a PK too? It has to be, if not, the validation logic in the designer should give an error. Could you attach a repro llblgenproj file for us to test?

I attach an even simpler project file llblgen project file only)

The FK (SourceDataId) here is Optional (nullable), so the multiplicity of the principal role must be 0..1.

And hence SourceDataId, is not a PK, then the multiplicity of the dependent role must be "*"

This is the workable association.

<End Role="ABillingProcessData" Type="Self.ABillingProcessData" Multiplicity="*" />
<End Role="ABillingDocumentSource" Type="Self.ABillingDocumentSource" Multiplicity="0..1" />

There is really a 1 to 1, but one of them is created (just) before the other, so there is a 1 to 0..1 momentarily.

We had intended for the first to be the ABillingDocumentSource, which means that the optional FK is really on the wrong side. The ABillingProcessData becomes the primary data when it is created which is why it has the FK

I think we are actually happy to swap it around so that ABillingProcessData can exist (momentarily) without a ABillingDocumentSource, but there is NEVER any multiplicity, but there is optionality.

are you saying I cant do that in EF6?

EF only supports 1:1 relationships between PK's. So A (pk) 1:1 B (fk) is only supported if the FK fields in B are the PK of B. Otherwise it's not supported. Your FK field in ABillingProcessData isn't the PK so EF doesn't support a 1:1 of that form (as it requires a Unique constraint on the FK fields, which is something EF can't do, it doesn't support unique constraints.)

Hi

Thanks for taking the time to explain that. Does nhibernate support 1 to 1? (Just out of interest)

Is there anyway that llblgen can generate a unique constraint at the db level?

fpdave100 wrote:

Hi

Thanks for taking the time to explain that. Does nhibernate support 1 to 1? (Just out of interest)

Yes, so does our own framework and linq to sql, just EF doesn't support it.

Is there anyway that llblgen can generate a unique constraint at the db level?

It automatically creates a Unique constraint for a 1:1 relationship in the model if the FK side fields aren't a PK. So... yes

I actually need to create a 1 to many (cos EF doesnt support the 1 to 1) but then put aconstraint on it to limit the number to a max of 1 on the db. Can I do that within llblgen, so ut will generate the sql script?

We do support that feature in the designer but not on EF (the validator will give an error) as EF doesn't support unique constraints at all. We raise the error to show the user EF doesn't support it, so we can't disable that error.

You could "implement" it at the db level for EF, by creating an appropriate constraint on the db.

fpdave100 wrote:

You could "implement" it at the db level for EF, by creating an appropriate constraint on the db.

That's what the designer does when you define a 1:1 relationship where the FK is not the PK (or when you define a Unique constraint in the designer on some fields).

I checked it and you can create a custom unique constraint in the entity on the FK fields (click the 'Unique constraints' sub tab on the Fields entity editor tab), then click 'validate and adjust the relational model' and the UC is created in the schema.

This doesn't make the relationship 1:1 though. Reverse engineering the schema back to an entity model will pick the FK up as a 1:1 relationship (as it has to decide it is a 1:1 relationship in that case).

So you can work around it this way.