Hi

after switching to the final version I get following error message during the refresh of a catalog:

Entity 'Element'
    Relation 'Element - ElementType (m:n) (via Element)' removed because one or more of its elements (FK/entities) were not found in the catalog.
    Entity migrated.
    Relation 'Element.ElementTypeId - ElementType.ElementTypeId (m:1)' removed because one or more of its elements (FK/entities) were not found in the catalog.
    Relation 'Element - ElementType (m:n) (via Element)' removed because one or more of its elements (FK/entities) were not found in the catalog.
Entity 'ElementType'
    Relation 'ElementType - Element (m:n) (via Element)' removed because one or more of its elements (FK/entities) were not found in the catalog.
    Entity migrated.
    Relation 'ElementType.ElementTypeId - Element.ElementTypeId (1:n)' removed because one or more of its elements (FK/entities) were not found in the catalog.
    Relation 'ElementType - Element (m:n) (via Element)' removed because one or more of its elements (FK/entities) were not found in the catalog.

I know and verified that the relation does exist. Any suggestions?

Christoph

I just checked the project. I thought I could work around this by adding a custom relationship. Problem here: Element.ElementTypeId is not available to do this.

Please post the database structure of the 2 tables envolved in the relation. With PK-FK types details.

Here it is:

Btw, it's an SQL Server 2005 Express

EDIT: I just checked the SQL Server 2000 (MSDE): Same error

And I refreshed the catalog of the same database with the August 8th version with no errors!

CREATE TYPE [dbo].[AssociationType] FROM [int] NULL
CREATE TYPE [dbo].[Bool] FROM [bit] NOT NULL
CREATE TYPE [dbo].[ElementType] FROM [uniqueidentifier] NOT NULL
CREATE TYPE [dbo].[EntityKey] FROM [uniqueidentifier] NULL
CREATE TYPE [dbo].[Locale] FROM [int] NOT NULL
CREATE TYPE [dbo].[Position] FROM [int] NULL
CREATE TYPE [dbo].[String1024] FROM [nvarchar](1024) NULL
CREATE TYPE [dbo].[String256] FROM [nvarchar](256) NULL
CREATE TYPE [dbo].[String512] FROM [nvarchar](512) NULL
GO

CREATE TABLE [dbo].[Element](
    [ElementId] [dbo].[EntityKey] NOT NULL,
    [ElementTypeId] [dbo].[ElementType] NOT NULL,
    [ContextParentId] [dbo].[EntityKey] NULL,
    [VariantMasterId] [dbo].[EntityKey] NULL,
    [ElementIsVisible] [dbo].[Bool] NOT NULL DEFAULT ((1)),
    [ElementIsVariant] [dbo].[Bool] NOT NULL DEFAULT ((0)),
    [ElementElementNameType] [int] NOT NULL,
    [ElementCreator] [dbo].[String256] NULL,
    [ElementModificator] [dbo].[String256] NULL,
    [ElementCreationDate] [datetime] NULL,
    [ElementModificationDate] [datetime] NULL,
    [LastAccess] [timestamp] NOT NULL,
PRIMARY KEY NONCLUSTERED 
(
    [ElementId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
GO

CREATE TABLE [dbo].[ElementType](
    [ElementTypeId] [dbo].[ElementType] NOT NULL,
    [Description] [dbo].[String1024] NULL,
    [IsOfElementType] [dbo].[String256] NULL,
    [NamingType] [dbo].[String256] NULL,
    [IsTranslationNeeded] [dbo].[Bool] NOT NULL,
    [InElementExplorerVisible] [dbo].[Bool] NOT NULL,
    [ElementIconFilename] [dbo].[String256] NULL,
    [ElementIcon] [image] NULL,
    [ElementIconType] [dbo].[String256] NULL,
    [ElementIconSize] [int] NULL,
    [ElementIconHeight] [int] NULL,
    [ElementIconWidth] [int] NULL,
PRIMARY KEY NONCLUSTERED 
(
    [ElementTypeId] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]
GO

/****** Object:  ForeignKey [ElementContextParent]  Script Date: 08/22/2007 16:54:10 ******/
ALTER TABLE [dbo].[Element]  WITH CHECK ADD  CONSTRAINT [ElementContextParent] FOREIGN KEY([ContextParentId])
REFERENCES [dbo].[Element] ([ElementId])
GO

ALTER TABLE [dbo].[Element] CHECK CONSTRAINT [ElementContextParent]
GO

/****** Object:  ForeignKey [ElementElementType]    Script Date: 08/22/2007 16:54:10 ******/
ALTER TABLE [dbo].[Element]  WITH CHECK ADD  CONSTRAINT [ElementElementType] FOREIGN KEY([ElementTypeId])
REFERENCES [dbo].[ElementType] ([ElementTypeId])
GO
ALTER TABLE [dbo].[Element] CHECK CONSTRAINT [ElementElementType]
GO

/****** Object:  ForeignKey [ElementVariantMaster]  Script Date: 08/22/2007 16:54:10 ******/
ALTER TABLE [dbo].[Element]  WITH CHECK ADD  CONSTRAINT [ElementVariantMaster] FOREIGN KEY([VariantMasterId])
REFERENCES [dbo].[Element] ([ElementId])
GO

ALTER TABLE [dbo].[Element] CHECK CONSTRAINT [ElementVariantMaster]
GO

Wild guess: the FK field is also a discriminator column? If so, this isn't possible anymore in v2.5: you can't have a discriminator column which is also an FK. Could you check that for me please?

This was changed 2 days before the final release, due to an issue that was reported in the case a discriminator column was indeed an FK.

Indeed it is a discriminator column. Changing this would break my model.

ChBaeumer wrote:

Indeed it is a discriminator column. Changing this would break my model.

But it's actually leading to errors at runtime, because the discriminator column is readonly. Also, it's unwise to make a discriminator column an FK, because it could make the type change (theoretically it could. At runtime LLBLGen Pro won't let you).

So how are you using this? You create an instance of type X, it sets the discriminator column to, say 4, and when you fetch the instance of X, it can load the related entity for the type with fk 4 ?

Hmm,

for me it is ok that the value is readonly since I never indented to change the type of an entity.

But what I do is to have some meta data for the type of the entity. And the naturally way of doing this (imho) is to use the discriminator field as FK to the table which contains the meta data.

EDIT:

So how are you using this? You create an instance of type X, it sets the discriminator column to, say 4, and when you fetch the instance of X, it can load the related entity for the type with fk 4 ?

Yes actually it did work till the final release. The data I load is meta data which do already exists in the database.

Hmm interesting scenario.

I must say that I don't really see a particular solution: if we allow FK fields to be discriminator columns, users run the risk of running into crashes at runtime which are hard to track down, as they could happen with pk-fk syncing in saves. We could of course add a note (as there is already present) to the docs but not everyone reads all 400+ pages

If we keep it as it is, you run into the problem that you can't have a related entity based on an FK set automatically.

Do you have a suggestion ? (Ok, besides reverting the change back as it was before ) We could of course revert this though that isn't really helping the other group of people who will then mark FK fields as discriminator fields and forget that it is a readonly field.

though that isn't really helping the other group of people who will then mark FK fields as discriminator fields and forget that it is a readonly field.

Can you allow the descriminator to be a fk but not allow it to be changed?

Good suggestion. But what does it mean:

1. When a discriminator field is a FK then it should be readonly?
2. When a discriminator field is no FK then it can be changed?

For me this would be fine. But the problem here is how to document this in a way people do read and unterstand the impacts for the db design.

my workaround know is the update the project catalog with the last working beta version and generate the model with the release version

The discriminator column is already readonly and thus can't be changed. If it's an FK, and there's a relation the problem is this: Say I have a hierarchy of CompanyCar entities and the discriminator field is CompanyCarTypeId. The field is an FK to CompanyCarTypes. That relation thus has a field mapped onto it, like any other relation.

So I can do this: FamilyCarEntity f = new FamilyCarEntity(); // fill data f.CompanyCarType = new CompanyCarType(); //... // save f.

when f is saved, the PK of CompanyCarType is synced with f's FK field, which happens to be a discriminator field. This goes wrong as the discriminator field is readonly.

What we did was disallow an FK become a discriminator field and also, if the field already is marked as a discriminator field when a relation is created: disallow the relation.

This breaks existing apps, however no new projects will arrive with this.

What we could do is disallow an FK become a discriminator field in the dialog, and still allow the relation to be created. However, this has the loophole that people can mark field X as discriminator field and then add a relation to the db, refresh and X is also an FK all of a sudden...

We're still thinking of what to do but we're leaning towards allowing the relations but not showing the field in the list of fields to pick the discriminator field from. This will limit the # of situations a lot, and the chance that someone still manages to make an fk field a discriminator field AND refuses to read the docs (although it's likely these go hand in hand ) is pretty small.

scratch

Hmm, does this mean that "old" project files having this feature (like mine) do work properly but new projects are not allowed to have discriminator fields AND the same field as FK?

This would mean that I have to backup my project on a lot of places so that it never gets lost This means too that I cannot setup a new project without changing the db model?

ChBaeumer wrote:

scratch

Hmm, does this mean that "old" project files having this feature (like mine) do work properly but new projects are not allowed to have discriminator fields AND the same field as FK?

This would mean that I have to backup my project on a lot of places so that it never gets lost This means too that I cannot setup a new project without changing the db model?

Good points... Hmm.

Ok, enough babble about this, I'll roll back the changes so people like you won't run into problems as it otherwise will have too much of an impact on your projects.

I'll see if I can add warnings somewhere, although people in general seem blind for these kind of things .

GREAT

Thank you

Christoph

ChBaeumer wrote:

GREAT

Thank you

Christoph

Change is in build: August 24th (or later) . Released coming sunday or monday.