What does this mean?

1 - **Do not define more than one foreign key on a single non-PK field. **Some people define more than one foreign key constraint on a single, non-primary key field and point these to two or more different table's primary key fields. This is bad schema design, even though SqlServer (and other databases) allows you to do this: LLBLGen Pro can't determine this way to which table (entity) the entity with the multi-fk constraints on one field relates to, using the field with the fk constraints.

examples?

2 - Design your concurrency scheme before you start creating a LLBLGen Pro project. LLBLGen Pro supports all concurrency schemes thinkable using the IConcurrencyPredicateFactory interface you can implement to specify per-entity concurrency control. If you want to use timestamp columns for example, be sure you define these up front in the schema.

Examples? "concurrency" scheme?

1 - Do not define more than one foreign key on a single non-PK field.

is this what that means http: //img525.imageshack.us/img525/2407/32340710.jpg ? <-- good or bad for LLBLGen? LLBLGen can handle this?

Khou wrote:

1 - Do not define more than one foreign key on a single non-PK field.

is this what that means http: //img525.imageshack.us/img525/2407/32340710.jpg ? <-- good or bad for LLBLGen? LLBLGen can handle this?

Bad design. LLBLGen doesn't support this. LLBLGen will take one relation of those (not two, not three, just one).

Khou wrote:

]2 - Design your concurrency scheme before you start creating a LLBLGen Pro project. LLBLGen Pro supports all concurrency schemes thinkable using the IConcurrencyPredicateFactory interface you can implement to specify per-entity concurrency control. If you want to use timestamp columns for example, be sure you define these up front in the schema.

It's just the recomendation that you should think and set the concurrency control you will use and put it on the DB before start llblgening

if that is bad design, what about this (same thing as above for different table)

http://img115.imageshack.us/img115/3717/59497448.jpg

how else would you design this?

1 - Do not define more than one foreign key on a single non-PK field.

is this what that means ? <-- good or bad for LLBLGen? LLBLGen can handle this?

No that's not what was ment by the warning note.

The following example is what is being warned about:

Task
-------
ID (PK)
Name


Event
-------
ID (PK)
Name


Contact
----------
ID (PK)
Name
ActivityID  (FK - 2 relations)

Where ActivityID is ment to target either Task.ID or Event.ID