Today I stumbled in one of the most nasty bug I have ever found. I have a form with 20 fields Named M01, M02... etc. till M20. There are also other fields, but those are ones with issues. When I created them I designed the first one and - as all of them share the same characteristics - I copied it and pasted, take in mind this. Today I added some OML code to enable / disable some fields - including all the M01, Mo2 etc fields - based on a rule. I used the setstate("M01",2) instruction. For some fields and for M01 field it worked, but for the others "Ms" fields it does not. I tried everything, but nothing seemed to change this behaviour. Finally I noticed that in the Columns pane fields have the correct name, while in the objects pane they have weird name: M012 M0111111 M01121 and so on. Now, do you remember how I created them? Yes, that is the tricky part: when I copy'n'paste a field DataEase gives it an arbitrary name and also if you change it the object still has that name. I had to change objects name manually.

Hi George, I copy paste fields a lot and I've never seen this as a bug tbh.

You always had to change the object name at the same time as field name after copying.  Just edit the field, change field name, the click the object name radio button and change that too.

I guess this is covered more or less, but will give some background.

When I first came across this "idiosyncrasy" i thought it was hilarious/stupid that there was two names for a field.

To top that, when you copied a field the ex. named Customer the new Field(Column name) would be Customer2 when the new Object Name would be Customer1... so you had the problem you describe (not synchronized) names even when you hadn't changed the column name.

This is since fixed so when you copy a Field the new names will be the same.

However, why is there two names if it so "obviously" isn't necessary?

So they CAN BE DIFFERENT!

Very good reason for that as it turns out.

A field or column name need to be unique inside the DataObject i.e. form/subform etc but there can be many CustomerNr for instance in one form as long as they are in different subforms etc.

GUI object however is not limited to a DataObject and can be accessed across the form. So SetValue("CustomerNr","Hello") will set the value of the FIRST CustomerNr in the form. So if you want to set values in the CustomerNr in subform X you have a problem.

You can in DE8 use SetValue("CustomerNr#3","Hello") to set the value in the third CustomerNr in the logical flow, but it is awkward, especially if you are going to manipulate a lot of clones (yes that is what all the CustomerNr's) in a subform is) so it is much better if you go in and change the ObjectName manually to something like sub2CustomerNr, then you can address all the CustomerNr clones in that subform from 1 to n.

So this is why a ObjectName could be different from the column, but why shouldn't the object change name when the Column change name?

Same reason. The OML code on an object use the name so if you make OML code on CustomerNr (2) in the flow it will end up on CustomerNr (1) in the flow because it need a unique name.

Another possible disaster with Objectname automatically changing when fieldname is changing, is exactly the sample you are using. You have used the objectname in a derivation in another field. It is then quite nice that the object name stay the same when you find that you need to change the field name or suddenly you would find that your code doesn't work.

If anything the biggest "fault" is that DataEase does not check if object names are unique when you insert a subform as you have the potential of "disaster" when you start putting OML on a non unique value, so the problem is really the opposite of what you "postulated" ;-)

The real "problem" here is the mindset. When starting to dabble with Manipulation you have to switch hat from User to Developer because you venture into the realm of complete freedom where he responsibility of the developer of getting things right also increase proportionally. 

Good luck and have fun.

PS! You are not allowed to define something as a bug, only we can do that ;-) It might just be "as designed"....

Is not a bug as long as you are aware of it, I spent more than an hour to figure it out.