I've just migrated my v2 project to v3, and try to refresh the schema from my sql database, the designer ask me to generate a ddl script to update the database first before refreshing, and the script generated is a set of sql creating foreign key on the sql database.

I haven't run the ddl script yet and continue to refresh the schema, the designer said foreign key cannot be found in database and removed the relationship in project.

In my current sql database, I haven't defined the foreign key relationship on most of the tables, I just defined the relation in LLBLGen v2 project and generate the entities.

Is it a must to define the same foreign key relationship in database for a v3 project?

You can turn off RelationshipsFollowDBForeignKeyConstraints on Project Properties.

Got it, setting RelationshipsFollowDBForeignKeyConstraints to false won't remove the relationship after refreshing.

If I want to create the foreign key on database by the generated ddl script, can I customize the foreign key name to be more meaningful instead of using a random guid as foreign key name by default?

If I want to create the foreign key on database by the generated ddl script, can I customize the foreign key name to be more meaningful instead of using a random guid as foreign key name by default?

Yes, I think.

I'm trying to customize the name of foreign key, I guess the name is construct in UpdateScript.lpt, line #306

string constraintName = foreignKeyConstraint.ConstraintName;

According to this line, I think this name is generated by designer. If I change the name here, generate ddl script again and update database structure, will it have any issues if I refresh schema from database next time?

I want to change the name to be more meaningful, like sql server default name , "FK[Child Table Name][Parent Table Name] "

I found that after I clicked "Validate and Adjust Relational Model Data", in the "Application Output" windows of designer, it shows it added a foreign key constraint and the name is in this pattern, "FK_[Guid]", and it will save this name in project file. I'm afraid if the constraint name is different on database, it will cause problems when refreshing schema.

No, FK names aren't compared, it checks target table and which fields are involved to see whether a relationship maps onto it and if it has to be migrated.

Is there by chance a way to turn off the requirement that relationships defined in the designer be set to foreign keys in the database, without turning off the creation of new relationships based on discovered foreign key constraints?

Basically what I have is some bad/old data that prevents the creation of a few foreign key constraints (and I don't have time to investigate the possibility of nulling that bad data out at the moment), but I need the LLBLGen relationships to be there. The RelationshipsFollowDBForeignKeyConstraints setting mentioned in this thread helps me with that situation obviously, but won't it prevent database refreshes from recognizing new relationships that exist in the database but not in LLBLGen? What happens if I create a series of new tables and refresh the database? Will the relationships based on FKs in the new tables not be created in LLBLGen? I am pained when I think of having to remember to manually create the relationships every time.

Thank you in advance for your attention.

We are aware of this situation, and we will address this in 3.1. The main problem is that the relationship in the model always has to have an equivalent FK in the relational model, or if you set a setting it simply won't need that, but that's a black/white switch, there's a grey area where you for SOME relationships you want this behavior and for some others you don't.

In general people won't run into this that often, but edge cases can happen which might force you to jump though hoops. My question to you is: if you can't add the FK to the DB, due to bad data, don't you think it will bug you at runtime when you fetch that data and it will turn out that the data is inconsistent and thus for example Fk field values don't match any PK value?

...don't you think it will bug you at runtime when you fetch that data and it will turn out that the data is inconsistent and thus for example Fk field values don't match any PK value?

You are 100% correct Otis; that bothers me a lot. However, the reality is that this data exists as it exists (before I came on the project), and while I don't have the authority yet to blow away that bad data, as a developer I do have the ability to create code that assumes good data. Then when the runtime error appears later I can point to that bad data as the culprit, possibly providing the impetus needed on high to be able to clear out that bad stuff.

In any case, the 3.1 mod sounds good. Thanks for your response.

Sounds like a nightmare scenario waiting to blow up on a rainy sunday morning at 4AM . I understand, and feel your pain. We hope to have something usable in the coming months, till then you have to jump through the hoops, I'm afraid, our apologies.