Our db has a table for which Llblgen generates code that fails compilation. The table has 2 keys that 5 FKs, specifically 2 points at one table and 3 at another. e.g., FK_MyTable_ClassType1 FK_MyTable_ClassType2 FK_MyTable_Type1 FK_MyTable_Type2 FK_MyTable_Type3

I believe this key 'multiplicity' throws it off.

The generated code that fails compilation is in two areas: 1. myTable.GetMultiManyToOne(null, null, null, null, null, null, this, null, null, null, null, null, null, null, null, null, filter); -- Where it should be myTable.GetMultiManyToOne(null, null, null, null, this, filter);

1. A block like the one below is defined multiple times (9x) instead of once. internal static readonly IEntityRelation MyTableEntityUsingTheTypeIdStatic = new TypeRelations().MyTableEntityUsingTheTypeId;

These compilation bugs are in many places about 30 code blocks, which ends up the code generation process (unfortunately) requiring manual and quite tedious effort.

Ron

Hi Ron,

You didn't post your LLBLGen version build. I assume that you are using v3.5, but maybe not the last build.

I can't reproduce it using similar scenario, see my attachment to see whether it looks like your scenario. I have this:

X Table

AId1 (PK)(FK to A) AId2 (PK) (FK to A) BId1 (FK to B) BId2 (FK to B) BId3 (FK to B)

A Table

AId (PK) Name

B Table

BId (PK) Name

If, after update to the latest version and regenerate the code you still have this behavior, please attach your .llblgenproj file. You can use a HelpDesk thread to do that, as it's private.

Hi David,

LLBLGen version=3.5.0.0 [build=11012012] I will test your attachment/code. However, if it works, we will need to do a WebEx to my machine.

Ron

David - your sample worked here but my example was missing important details.

1) There is a duplicate/copy FK. 2) There is also a multi-column index in which this problematic column participates. But I'm assuming LLBLgen disregards indexes. Right?

Here's the revised model:

Table X

StrID -PK FlrTID -FK to table T (FK_X_T) ** dup. FK to T (FK_X_ccT) ClmTID -FK to table T DrTID -FK to table T ClsTID -FK to table T

Table T

TID (PK) Name

Thanks, Ron

I don't understand what you mean by "duplicate copy FK". What is "** dup. FK to T (FK_X_ccT)" ? It it's a duplicate FK, then Why do you need it?

David - yes, it is a duplicate foreign key (same references/contrains just under a different key name). I don't know the history of why it's there. But I believe this will cause the compilation problems.

Please confirm I'm right and provide a fix or at least a Validation warning about this problem, or some kind of remedy.

The bottom line is that I'm getting 30 compilation errors, and every time I update/refresh the model, and regenerate the code, there is a very tedious/manual effort.

Note: I need confirmation from your side that this breaks the Code Generator/compilation on your side.

Ron

This must be the issue, indeed. From the designer, please remove this extra field from the specified entity, and re-generate the code.

Removing the duplicate FK did not fix the problem.

The problem is up stream, before code generation. I can see 10 extra/bogus relationships inside LLBLGen Designer on the Model tree (left side).

The bug must be not in DB refresh, not code generation. The refresh creates a bad model. And then, the code generator creates code that can't be compiled.

Ron

RonENT wrote:

Note: I need confirmation from your side that this breaks the Code Generator/compilation on your side.

Hi Ron. I can't reproduce it over here with your instructions. This is what I've done:

1. Create a DB similar like this:

X Table

Id (PK) TId (PK) (FK to T) ** dup FK to T (named FK_X_ccT) TId1 (FK to T) TId2 (FK to T) TId3 (FK to T)

T Table

TId (PK) Name

1. Create a LLBLGen project
2. Create the model from that DB
3. Generate code for .net4/SelfServicing
4. Compile the code. I receive errors like these:

Error 1 The type 'Multiplicity.RelationClasses.XRelations' already contains a definition for 'TEntityUsingTid' ...\Code\RelationClasses\XRelations.cs

Error 5 Ambiguity between 'Multiplicity.RelationClasses.XRelations.TEntityUsingTid' and 'Multiplicity.RelationClasses.XRelations.TEntityUsingTid' ...\RelationClasses\XRelations.cs

Those errors are expected since I have duplicate FK... so:

1. Go to the LLBLGen project and delete the extra "relation" on T (the one that reference the same FK field)
2. Regenerate code, now everything compiles fine.

My recommendations are: A. Whenever possible, fix the DB. After all the problem originates there. B. Update to the latest LLBLGen Pro. The latest is "v3.5 Final (November 6th, 2012)". C. Go to your LLBLGen project and remove the extra "relation". Doing that will automatically remove the other side's relation and the involved navigators. Then regenerate code.

If you still experience problems, try to reproduce it with the example I'm attaching (btw I will delete the previous one to save space). If you can't reproduce it with that, please create a HelpDesk thread and attach your .llblgenproj and the DLL of you DB schema.

David,

1. Yes, the upgrade addressed the issue.
2. Is there a way to do a 'selective Refresh' or re-GenerateCode selectively that will provide only files that have changed.

Example: I change one column type from double to int in a 200-table db. All tables need to be refreshed, and all code, that translates to 500+ files. In reality, only about 15 files changed. So the question, is there a better to way to handle this one column change. e.g., - select only that table (I tried this - and it doesn't work- the model will collapse to that table) - generate code will 'focus' on the change.

Thanks, Ron

Hi David - one more issue

1. After the upgrade the runtime DLLs' file sub-versions did not change For example. SD.LLBLGen.Pro.DQE.Access.NET20.dll -> version= 3.5.12.0703 before & after upgrade

Could you address this? e.g., 3.5.12.0703 before upgrade 3.5.12.0925 after upgrade

Ron

DQEs rarely change. You should be checking the ORMSupportClasses...dll

What's the problem for regenerating the files, other then the time measure?

I have the code under source control and tracking differences. It's very tedious to manually figure out which files have changed vs. which ones are identical (=irrelevant). The culprit is the timestamp comment placed in each .cs (underlined below) including unchanged files. This means all files end up being different although 99% of them are identical other than the comment time stamp.

-Is there a way to have the comment/timestamp update only where there is a real change? OR - remove the timestamp altogether?

/////////////////////////////////////////////////////////////// // This is generated code. ////////////////////////////////////////////////////////////// // Code is generated using LLBLGen Pro version: 3.5 // Code is generated on: Tuesday, November 20, 2012 8:52:34 AM // Code is generated using templates: SD.TemplateBindings.SharedTemplates.NET20 // Templates vendor: Solutions Design. // Templates version: //////////////////////////////////////////////////////////////

Ron

RonENT wrote:

-Is there a way to have the comment/timestamp update only where there is a real change? OR - remove the timestamp altogether?

Yes, there is. Go to Project->Settings->LLBLGen Pro Runtime Framework. Then turn off the 'Tdl emit time date in output files' setting.

Hi David,

a) I was looking for this setting under CodeGenerator and couldn't find it. Is this misplacement in essence a UI 'bug' since this is part of the code generation process as oppossed to runtime details?

b) It worked- thanks.

Ron