I have a database that has 3 tables (for example)

A has a ?:n with B

A has a ?:n with C

B has a m:n with C (via a link table BC)

where ? is 0 or 1 ie nullable field.

now it seems the LLBLGen will connect all these options togther and give me 2 paths, 1 from each object to the other going via the 3rd, and the direct link.

Some of these paths aren't required in the business logic ie C does not need to know it has many A, nor does it need to connect to B via A siince it should use its more direct m:n link table.

However when I remove these relationships in the LLBLGen UI the generated code tries to use them - normally after I regenerate the code after a db change. Am I doing something wrong? I assume I can delete these relationships I just don't seem to be able to get them to not be used after a couple of re-generations. I hope this makes sense and is just user error.

The other is when I remove an entity I don't need in the business code and is acting as a database lookup/constraint to limit certain values to specific known values. Sometimes the templates try to use that entity.

It could be that it creates a new .vbproj that still references the files for the entity that I removed.

Shaun

CodeMonkey wrote:

I have a database that has 3 tables (for example)

A has a ?:n with B A has a ?:n with C B has a m:n with C (via a link table BC) where ? is 0 or 1 ie nullable field.

now it seems the LLBLGen will connect all these options togther and give me 2 paths, 1 from each object to the other going via the 3rd, and the direct link.

Some of these paths aren't required in the business logic ie C does not need to know it has many A, nor does it need to connect to B via A siince it should use its more direct m:n link table.

However when I remove these relationships in the LLBLGen UI the generated code tries to use them - normally after I regenerate the code after a db change. Am I doing something wrong? I assume I can delete these relationships I just don't seem to be able to get them to not be used after a couple of re-generations. I hope this makes sense and is just user error.

An m:n relation is based on 1:n relations. If you hide one of them, the m:n relation is not possible. It is recommended that you keep 1:n relations and hide m:n relations if you want to limit the amount of relations visible.

You can also hide fields mapped on relations. This is a recommended way of limit the amount of fields in an entity when you do not need all those properties.

The other is when I remove an entity I don't need in the business code and is acting as a database lookup/constraint to limit certain values to specific known values. Sometimes the templates try to use that entity. It could be that it creates a new .vbproj that still references the files for the entity that I removed. Shaun

When you remove an entity, the code files are not removed from the generated project. This is by design. It can be some files are still left in your project.

Ahhhh - I see - I assumed the generated code would cope - I suppose then the best way to hide this in the business logic side is to use the Entity Classes to hide the properties you do not want exposing ie protected or internal

CodeMonkey wrote:

Ahhhh - I see - I assumed the generated code would cope - I suppose then the best way to hide this in the business logic side is to use the Entity Classes to hide the properties you do not want exposing ie protected or internal

You can hide the fields mapped on relations in the designer which is for this scenario the best thing to do I think

You can hide the fields mapped on relations in the designer

I tried that but it seems that when I have the following

A 1:m B

B m:1 C

then when I want to A.C type mapping then but not the C.A mapping - it seems that I can't hide the C.A mapping without breaking the A.C one.

I'll try an make a sample project that exhibits the behaviour and send it to you.

Shaun

Okay I have a sample using the following database

CREATE TABLE [dbo].[Table1] ( [ID] [int] NOT NULL , [DateCeated] [datetime] NOT NULL ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Table2] ( [ID] [int] NOT NULL , [Table1ID] [int] NOT NULL , [Table3ID] [int] NOT NULL , [AdditionalProperty] [money] NOT NULL ) ON [PRIMARY] GO

CREATE TABLE [dbo].[Table3] ( [ID] [int] NOT NULL , [DateCreated] [datetime] NOT NULL ) ON [PRIMARY] GO

ALTER TABLE [dbo].[Table1] WITH NOCHECK ADD CONSTRAINT [PK_Table1] PRIMARY KEY CLUSTERED ( [ID] ) ON [PRIMARY] GO

ALTER TABLE [dbo].[Table2] WITH NOCHECK ADD CONSTRAINT [PK_Table2] PRIMARY KEY CLUSTERED ( [ID] ) ON [PRIMARY] GO

ALTER TABLE [dbo].[Table3] WITH NOCHECK ADD CONSTRAINT [PK_Table3] PRIMARY KEY CLUSTERED ( [ID] ) ON [PRIMARY] GO

ALTER TABLE [dbo].[Table2] ADD CONSTRAINT [FK_Table2_Table1] FOREIGN KEY ( [Table1ID] ) REFERENCES [dbo].[Table1] ( [ID] ), CONSTRAINT [FK_Table2_Table3] FOREIGN KEY ( [Table3ID] ) REFERENCES [dbo].[Table3] ( [ID] ) GO

I then

1) loaded this into LLBLGEN and made sure I had all 3 entities

2) went to Table3 and removed its Table1 (from fields mapped on relations).

3) generated the code using "two class scenario full/safe - 2003".

4) loaded the project in VS.NET and compiled

I then get the following errors generated

E:\sources\windows\Pseudo\EntityBaseClasses\Table1EntityBase.cs(566): 'Pseudo.CollectionClasses.Table3Collection' does not contain a definition for 'GetMultiManyToManyUsingTable1'

E:\sources\windows\Pseudo\EntityBaseClasses\Table1EntityBase.cs(587): 'Pseudo.CollectionClasses.Table3Collection' does not contain a definition for 'GetMultiManyToManyUsingTable1'

and on both occasions it is the fllowing line of code

_table3.GetMultiManyToManyUsingTable1(this);

This is a known issue for Selfservicing: if you use selfservicing, you have to hide / unhide the fields/relations in pairs.

Okay will do (or not as I want one of the relationships)

However is this a TODO?

Thanks

CodeMonkey wrote:

Okay will do (or not as I want one of the relationships)

However is this a TODO?

Thanks

Yes. It's open bug #2.