Hi, we encountered a strange behavior in LLBLGen 2.0. We are working on a project and designed a database which we used to generate the LLBLGen code. Later we decided to change some table names and we had to regenerate the code. The strange thing is that some of the entities where not matching the right tables anymore. I htink this is a bug in the LLBLGen.

For this reason we decided to start a new project so the new entities were created matching the right tables. Unfortunately because we choose to create a new project, we also had to change our businesslogic (changing entitienames which were used based on the first project we created), but that is normal because we changed the project so all entities where new. That is, entities which table names where changes.

My questions: - Is this a bug? Seems to me it is. - Is it possible to change the entity through the LLBLGen interface so you can change the matching table if it would be wrong, like we experienced? - Any other suggestions?

We use the adapter variant to generate the code.

Thanks.

Hi,

Did you change both DbGeneric and DbSpecific projects in your solution when you regenerated the code ? Also are you using a sourcecode managment program (like Visual SourceSafe) ? (if some files are readonly, it can cause the problem you describe)

By the way changing some table names and refreshing the catalog should work fine. As far I know, there are no known bugs on this.

Hi there, I'm sorry, but we checked if we could reprocduce this behavior and we could. I will attach the generated report by LLBLGen. Take a look at the following tables:

Small example. Ohter mismatches can be found in the attachment.

The table [DailySupport] should point to [AAMRDailySupport] but as you can see points to [AAMRLimition]

The table [Limitation] should point to [AAMRTypeSupport] (in the attachtment is abvreviated to dbo. rt--> this is also generated by LLBLGen maybe an other bug. it should be dbo.AAMRTypeSupport) and it points to [AAMRLimition].

It looks like circulaire mismatching. If one table is mismatched others are also affected..

Additional information, just to make sure, this code/project was not under a kind of source control. We use ms sql 2005 and LLBLGen pro 2.0.

Hi,

what release of llbl do you have? Did you try to download the lastest one? Did you only rename table or do you also rename field(and PK/FK)? Because it seems that llblgen didn't find any more your old FK and so have a problem to change the link.

This is caused by the fact that the refresher has to make a choice between which table to target as it's original table is renamed. It then finds one based on the fields/types and chooses that one. This can be the wrong one as you found out.

To overcome this, please do the following: - make sure you're using the .lgp backup file created prior to the refresh - go to preferences and set ManuallySelectRenamedTargetsAfterRefresh to true - perform your refresh again, using that BACKUP file.

You'll now get a form with the entities which tables have been renamed and couldn't be found. You can then select manually which tables these entities should be mapped on.

In the entities overview list (rightmouse on 'Entities' -> View entities list, you can see which entities are mapped onto which targets.

Thanks Otis, this works. We now understand why it was generating the wrong mappings.

Your solutions works fine.

Thanks.

This threat can be closed.

oeps

oeps1

Otis wrote:

• go to preferences and set ManuallySelectRenamedTargetsAfterRefresh to true

Cool very helpful feature. I'm glad I just found this post.

Thanks, Patrick