Forum:  Bugs & Issues

Thread:  After Tablename change some entities not matching right table anymore

Stephan (User)   Posted on: 14-May-2007 10:44:38.
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.

Aurelien (Support Team)   Posted on: 14-May-2007 15:17:43.

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.

Stephan (User)   Posted on: 14-May-2007 15:55:47.
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..

Stephan (User)   Posted on: 14-May-2007 16:20:30.
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.

jbb (User)   Posted on: 14-May-2007 16:35:41.

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.
Otis (LLBLGen Pro Team)   Posted on: 14-May-2007 16:49:10.
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.

Stephan (User)   Posted on: 14-May-2007 17:08:40.
Thanks Otis, this works. We now understand why it was generating the wrong mappings.

Your solutions works fine.


This threat can be closed.
Pablo (User)   Posted on: 13-May-2008 16:20:11.

Pablo (User)   Posted on: 13-May-2008 16:22:42.
pat (User)   Posted on: 16-Jul-2008 02:46:39.
Otis wrote:

- go to preferences and set ManuallySelectRenamedTargetsAfterRefresh to true

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