LLBLGen v: 1.0.2005.1, Nov 8th 2005 SQL Server 2005

I have a simple class hierarchy setup using the TablePerEntityHierarchy model. The super class is based on a view and so I manually select the primary key column.

Whenever I create a custom relationship between a subclass and any other class, the relationship is dropped by LLBLGen on a catalog refresh with the following error:

Custom relation 'SubClass.ForeignKey - Class.PrimaryKey (m:1)' removed because one or more of its elements were removed during the process or have changed (not in the PK anymore etc.).

Any relationships defined between non-subclass entities are preserved.

Why do the relationships defined on sub-classes get dropped? Everytime I refresh the catalog I have manually recreate the relationships for subclasses.

Any clues much appreciated, Stef

Will look into it. Might be a bug where the PK is reset while it should be preserved (I think that's the cause for the behavior you're seeing).

(edit) reproduced. The relation is still there, the PK is still set in the view, the subtype definition is just gone. Bug in refresher, I'll fix this.

Fixed in next build.

Otis wrote:

Fixed in next build.

Awesome, thank you.

Hi Frans,

Just installed the latest release (Nov 17th) and the problem is still there. In the release notes:

15-nov-2005: (Core, 1.0.2005.1.November 15th): * FIX : If a supertype/subtype hierarchy of type TargetPerEntity is setup and one of the elements is a view, the hierarchy is removed in a refresh of the catalog.

I am using TargetPerEntityHierarchy, rather than TargetPerEntity, should the issue be fixed for both types of subclassing?

Thanks, Stef

stef wrote:

Hi Frans,

Just installed the latest release (Nov 17th) and the problem is still there. In the release notes:

15-nov-2005: (Core, 1.0.2005.1.November 15th): * FIX : If a supertype/subtype hierarchy of type TargetPerEntity is setup and one of the elements is a view, the hierarchy is removed in a refresh of the catalog.

I am using TargetPerEntityHierarchy, rather than TargetPerEntity, should the issue be fixed for both types of subclassing? Thanks, Stef

Hmm. I found that the routine which checks graphs after a refresh only considered non-custom relations so if a custom relation was used to build a hierarchy it couldn't find back it's new version (as it wasn't a db relation), and removed it. I fixed that. I thought that was your problem.

Your error: "Custom relation 'SubClass.ForeignKey - Class.PrimaryKey (m:1)' removed because one or more of its elements were removed during the process or have changed (not in the PK anymore etc.)." is about a custom relation being removed, which has nothing to do with TargetPerEntityHierarchy hierarchies, as these aren't build with relations but with a discriminator column.

I'll re-examin your issue with the startpost. I fear I have accidently looked into the wrong direction (and by accident found a bug you didn't report, which is ok, but not helpful to you ).

Reproduced (and now it is your situation ). Working on fix.

(edit) Fixed in next build.

Otis wrote:

Reproduced (and now it is your situation ). Working on fix.

(edit) Fixed in next build.

Hi Frans, Installed the Nov 18th release and I still get the same issue. Would it help if I sent you my project file and database schema?

Thanks, Stef

maybe it would be solved in the Next Build since Frans' last reply was on the 18th of November

It should be fixed in nov 18th release.

Sending me a schema doesn't work, I need to know what changed since the last project refresh. For example if the field in the view that's the PK has been changed to a different type or something else, the relation is removed. However I could reproduce your problem but can't reproduce it anymore since I fixed the cause of it.

So what I need is a repro case: - you have a schema - you create a project - you alter the schema (detailed steps 1 2 3) - you refresh - boom, all relations you created are gone.

OK, here's a list of the steps to reproduce - just to be sure I started from scratch...

Environment: Windows XP SP2 SQL Server 2005 (RTM) LLBLGen v1.0.2005.1 (November 18th)

1. Create new database called LLBLGenSample

2. Create new tables as follows:

CREATE TABLE [dbo].[Campaign]( [ID] [int] NOT NULL, [CampaignTypeID] [int] NOT NULL, [Discriminator] char COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL, [Name] varchar COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL, [Description] varchar COLLATE SQL_Latin1_General_CP1_CI_AS NULL, [Location] varchar COLLATE SQL_Latin1_General_CP1_CI_AS NULL, CONSTRAINT [PK_Campaign] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY]

CREATE TABLE [dbo].[CampaignType]( [ID] [int] NOT NULL, [Discriminator] char COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL, [Name] varchar COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL, [Description] varchar COLLATE SQL_Latin1_General_CP1_CI_AS NULL, CONSTRAINT [PK_CampaignType] PRIMARY KEY CLUSTERED ( [ID] ASC )WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY] ) ON [PRIMARY]

No relationships are defined between the tables.

1. Create views to create the entities from, the views are:

CREATE VIEW [dbo].[CampaignDC] AS SELECT ID, CampaignTypeID, Discriminator, Name, Description, Location FROM dbo.Campaign

CREATE VIEW [dbo].[CampaignTypeDC] AS SELECT ID, Discriminator, Name, Description FROM dbo.CampaignType

1. Create a new LLBLGen project

2. Point to the database and retreive the schema for views and stored procedures (I used trusted security).

3. Create entities based on the views: * CampaignEntity based on view CampaignDC * CampaignTypeEntity based on view CampaignTypeDC

4. Set the 'ID' atttribute in each entity to be 'part of the primary key' (this maps to the ID column in the DB which is the PK)

5. Create a new subtype from Campaign, called Event and set the discrimintor column: Campaign - C Event - E

6. Create a new subtype from CampaignType called EventType and set the discriminator column: CampaignType - C EventType - E

7. Add a new m:1 relationship between Event and EventType where Event.CampaignTypeID is mapped to EventType.ID

8. Without changing the database schema, choose refresh catalog and the relationship between the sub classes will be removed.

Cheers, Stef

Thanks Stef! I'll check it out. First on sqlserver 2000 and then on sqlserver2005.

(edit) reproduced on 2000.

My test succeeded and your test failed because the end entity in the relation is also in a targetperentityhierarchy. A related problem with derived UC's is also present. Fixing that too.

(edit) Fixed in next build (and now for real ). Can I mail you the .dll for testing to be sure?

Sure, that would be ideal. Can you get my email address from the forum system or would you like me to post it here?

Stef

stef wrote:

Sure, that would be ideal. Can you get my email address from the forum system or would you like me to post it here? Stef

I'm the admin here, I can see everything You'll receive the .zip in 5 minutes

(edit) On its way!

(edit2). blocked by spamfilter.. .

Installed the DLL you sent out and the relationships are now preserved after a catalog refresh.

Thanks for all your help, Stef