Hello,

I run into the following problem:

1) Using the designer I'm modifying a "Fields mapped on relations" default fieldname on a relation of type m:1, hidden=false. 2) I save the changes to the project file. 3) I generate the code (F7)

Result: In my code I can use the modified fieldname. Perfect!

Then .... the problem:

From within VS2008 I use a batch file to refresh the model and regenerate code (using the same project as I used in the designer, and using CliRefresher.exe and CliGenerator.exe). However, when I run this batch file, the manually modified field name is being replaced again by the autogenerated default fieldname.

My question is: should this work like this, or could I expect the manually changed fieldname to remain changed as desired. What can I do to preserve the fieldname?

Paul

ps. I'm using llblgenpro version 2.5 dec 5th 2007

If you re-open the Designer before using the batch file to refresh and regenerate the code, would you find the field name as you have renamed it?

And now (after refresh and re-generation) if you open the Designer would you find the original field name or the renamed one?

Hello Walaa, thanx for the quick reply. I tested it again with refreshing in the designer .... And indeed ... now it also changes back to the default.

I found the following message in the refresh log:

Field 'Portal_ChildPortal' mapped onto relation 'Portal_SiteMapRule.ChildPortalId - Portal_Portal.PortalId (m:1)' has been renamed to 'Portal_Portal_' (Sync with name of target)

Portal_ChildPortal is the name I gave it manually, Portal_Portal_ is the name it was given by llblgen. So this shows that it actually is overriden by the refresh process.

hummm ... now what?

Paul

ps: I looked at project settings, found: SyncMappedElementNamesAfterRefresh = true

I put this on true, in order to make sure that changes to the datamodel would immediatly appear in the regenerated code. Which is still what I want without exception ... ahum, except this exception.

The problem is that the fieldname llblgen generates is not coming from the database either, it is a 'creation' of logic in llblgen. Do you see a way of dealing with this???

This issue was discussed before: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=12575 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=8982

Walaa,

I read those links. It indeed 'kind-off' talks about the same topic. However i see a difference.

With the setting of SyncMappedElementNamesAfterRefresh is set to true, one counts on the fact that each change in the database is reflected in the 'refreshed' and 'regenerated' code. I hope this will never change!

The exmaple otis gives, with a field ABC in the db, changed manually to XYZ in the designer. Later changed in the db to DEF .. etc.. this is all ugly. I don't want this type of discrepancies ... therefore 100% mapping.

However .... fields mapped on relations gives the field a name which is not 100% derived from the database, the trailing underscore to the fieldname is a 'creation' of the llblgen logic.

In this case a different solutions can be thought of, I'm sure.

Paul

But it's also generated based on the database table name. So if Order has a Customer filed mapped on the relation, then on the database you rename the Customer table to be "Client", when you refresh the catalog with that flag turned on, the field should read Client instead of Customer.

We've added a feature to v2.6, where you can say that manually renamed field names (and fields mapped onto relations) aren't affected by the sync feature. So in v2.5, this wasn't fixable, as it would require information stored inside the project file which then would cause versioning issues among users, however in v2.6 this should work properly: after you've renamed the field, the field shouldn't be changed back, if you've set 'SyncRenamedFieldElementsAfterRefresh' to false

Walaa & Otis ... Briljant!!! Thanx very much!!!

Paul