Hi,

I have an entity "downloadable" that has a pair of derived (TargetPerEntityHierarchy)entities, "downloadableExecutable" and "downloadableDocumentation". Performing a refresh of the catalog causes the derived entities to be renamed to "downloadable" and "downloadable_" respectively. Any ideas why this is happening?

Thank you!

Hello,

what version of llblgen do you use? Did you try to download the latest version?

I am using 2.0.0.0 Final Released on December 6, 2006. I will download and update to the January release and followup here.

Hello,

Ok for your realease, in the release of January, there was an update about inheritance and refresh problem. So download the latest version and give us a feedback about your problem.

I downloaded and installed the latest version 2 (January 23, 2007) and the problem still occurs.

Here is the DDL for the base entity, and its decriminator column "TypeId".
create table dmDownloadable ( timestamp, id int constraint PK_Downloadable primary key, -- id of the content TypeId int not null default(0) CONSTRAINT FK_DownloadableType foreign key references dmDownloadtype(id), Visible bit not null default(1), -- 1 = visible, 0 = not visible Name varchar(100) not null, ReleaseDate datetime not null default (getdate()), -- release date of the download Version varchar(100) null, -- version of the download Description varchar(255) not null, -- description of the content shown to user ContentId int null CONSTRAINT FK_DownloadContent Foreign key references dmContent(id), -- full page decription of the content. FileName varchar(255) not null, -- Name the content relative to App_Data\downloadables SortOrder int not null default(5), OperatingSystem varchar(100) null, -- for executables, the OS version required (this is null if download is a doc). DocumentType varchar(100) null -- for documents, the type of the document (this is null if download is a exe) ) GO ALTER table dmDownloadable ADD constraint UK_DownloadableNameRelease unique(name,releasedate) GO

create table dmDownloadType ( id int constraint PK_DownloadType primary key, Name varchar(100) not null constraint UK_DownloadTypeName unique, SortOrder int not null default(5) )

Could you post the script for your child entity too, i will test it(and says me on what database engine is for, ms sql I presume) ?

With my inheritance testprojects (all hierarchy types) I can't reproduce it.

jbb wrote:

Could you post the script for your child entity too, i will test it(and says me on what database engine is for, ms sql I presume) ?

Not sure what child entity you are referring to. I am using Selfservicing and SQL server 2000 (<add key="SqlServerDQECompatibilityLevel" value="1"/>)

I think he referred to the derived entities You gave 1 table. Is the whole hierarchy mapped onto the same table, or do you have per entity a table?

Otis wrote:

I think he referred to the derived entities You gave 1 table. Is the whole hierarchy mapped onto the same table, or do you have per entity a table?

Sorry, i misunderstood that. Yes, the whole hierarchy is based on a single table "dmDownloadable", with a descriminator field "typeid".

Just to be sure:

downloaded and installed the latest version 2 (January 23, 2007) and the problem still occurs.

Do you mean the underscores are still there? Or do you mean if you re-named the entities correctly and then re-fresh the catalog again, they are altered again to contain the underscores?

Do you have the same names used in another entities/tables?

Walaa wrote:

Just to be sure: Do you mean the underscores are still there? Or do you mean if you re-named the entities correctly and then re-fresh the catalog again, they are altered again to contain the underscores? Do you have the same names used in another entities/tables?

"DownloadableExecutable" is renamed to "downloadable_" "DownloadableDocument" is renamed to "downloadable"

No i do not have the same names used in other entities. The code actually compiles and creates the derived entity/collections "DownloadableExecutable" and "DownloadableDocument". It is when I later refresh the catalog that the designer renames these entities.

Hello,

I can't reproduce it, could you post your lgp files or send us by email?

jbb wrote:

Hello,

I can't reproduce it, could you post your lgp files or send us by email?

The file is 342K, where shall I email it to?

You can send id at support AT llblgen.com.

I'll use the table structure you posted to be able to refresh the project. If you can also include DDL SQL for the schema it would be great, though it's not really necessary, as long as the table structure you posted above is the structure of your table now.

Do you by any chance have the Preference setting 'SyncMappedElementNamesAfterRefresh' set to true?

If so, I think it's the cause of it.

Otis wrote:

Do you by any chance have the Preference setting 'SyncMappedElementNamesAfterRefresh' set to true?

If so, I think it's the cause of it.

That happens in our setup, so we had to change SyncMappedElementNamesAfterRefresh to false so it wouldn't mess up the inherited entity names. We had it set to true before though, and would have liked to keep that behavior...

I'm a little undecided still if this is a bug or not. The thing is that if you set this to true, the names should be synced, however with a hierarchy on a single table and also multiple entities on a single table, it's not really paying off.

Excluding these, will make the feature work, however at the same time doesn't sync the names properly so why enabling it at all...

What do you suggest we should do, you're using this feature: should we exclude targets with multiple elements mapped onto it, or should we keep the feature as is and if you run into this (you're the first ) you should switch the feature off?

Otis wrote:

I'm a little undecided still if this is a bug or not. The thing is that if you set this to true, the names should be synced, however with a hierarchy on a single table and also multiple entities on a single table, it's not really paying off.

Excluding these, will make the feature work, however at the same time doesn't sync the names properly so why enabling it at all...

What do you suggest we should do, you're using this feature: should we exclude targets with multiple elements mapped onto it, or should we keep the feature as is and if you run into this (you're the first ) you should switch the feature off?

Not sure if this question was directed at me, but I'll answer anyways

One of the problems is that there is no distinction between when a user manually changes a name of a field or entity in the designer, and when the refreshed catalog changes. If I manually changed the name of an entity or field, I most likely don't want it changed back on the next refresh of the catalog, so I can't see when this would ever be the right thing to do. However, if an actual table name, or field name changes, any "non overriden" names should probably change also.

I know this isn't a very good solution because how would you get an entity or field name back in sync? You could have checkboxes next to every entity and field which could exclude them from the sync process but that would be a pain.

All I can really say is that inherited entities and multiple entities based on the same table should almost definitely be always excluded from the sync process. That would solve our problem at least

mikeg22 wrote:

Otis wrote:

I'm a little undecided still if this is a bug or not. The thing is that if you set this to true, the names should be synced, however with a hierarchy on a single table and also multiple entities on a single table, it's not really paying off.

Excluding these, will make the feature work, however at the same time doesn't sync the names properly so why enabling it at all...

What do you suggest we should do, you're using this feature: should we exclude targets with multiple elements mapped onto it, or should we keep the feature as is and if you run into this (you're the first ) you should switch the feature off?

Not sure if this question was directed at me, but I'll answer anyways

One of the problems is that there is no distinction between when a user manually changes a name of a field or entity in the designer, and when the refreshed catalog changes. If I manually changed the name of an entity or field, I most likely don't want it changed back on the next refresh of the catalog, so I can't see when this would ever be the right thing to do. However, if an actual table name, or field name changes, any "non overriden" names should probably change also.

You mean a distinction between when a field is renamed by the user in the designer vs. when a field is renamed in the DB?

At the moment, the sync routine is ran after the refresh. So it checks all names, if they're the same as the mapping name would be. If not, it resets the name.

The sync routine is meant to reset names of entities of which the target table was renamed or target field was renamed etc.

You'll see a conflict of interest here: what if a hierarchy is mapped on such a table? Obviously it will lead to things like you experienced, however by excluding it, it makes the feature actually not useful: the reason it's there is bypassed.

I know this isn't a very good solution because how would you get an entity or field name back in sync? You could have checkboxes next to every entity and field which could exclude them from the sync process but that would be a pain.

All I can really say is that inherited entities and multiple entities based on the same table should almost definitely be always excluded from the sync process. That would solve our problem at least

heh Yes I know, though I then think disabling the feature would be better. The refresh log tells you if an entity is mapped onto a different table/view. There's no feedback for if a field is now mapped onto a field with a different name. If I add that you could leave the feature off, and use the log. This rename detection isn't logged because it determines it's the same field so why log that it's mapped onto the same field (albeit renamed)...

I know it's not automatic, but it would give the information to correct the project, IF required, properly, as the code itself can't make this decision (IMHO).

_Hello,

Ok for your realease, in the release of January, there was an update about inheritance and refresh problem. So download the latest version and give us a feedback about your problem. _

Question: I am trying to resolve a similar problem, but when I download the trial version I continue to get the 2.0 July version, not a January version that has this problem fixed. Is the January version not available for trial? Tx.

The demo download is the latest build, not a july build. Could you try frm the download mirror instead? It might be you're using a download accelerator or cache somewhere which serves you an old version

_The demo download is the latest build, not a july build. Could you try frm the download mirror instead? It might be you're using a download accelerator or cache somewhere which serves you an old version _

I use the download mirror but still get from the Help->About screen that it is version 2.0.0.0 from July 2006 - nothing about January 2007. We don't use any download accelerator or cache. Could you please confirm that the demo version's About->Help reflects the fact that it is an update? Or change the filename of the updated demo version? Tx.

I can, the msi file is of 19-feb-2007... The date in the titelbar/about is February 14th 2007. I downloaded the .msi file from the official download link.

I have no idea how you can end up with a july build...