ERC not matching fields

[MCCInet]

I am comparing a program against the PYSAVE version of the same program, and there are some fields that it does not recognize as being the same in Event Rule Compare (ERC).

The fields have identical names and it is the same control "EDIT" - "Control is Exited/Changed In-Line" within the same Form.

ERC shows the PYSAVE field near the top of the form in blue with no LOCAL ER's. It shows the identical field name lower down in the same form in Green with no PYSAVE ER's.

Since it does not recognize them as being the same field I cannot move the code over.

Any ideas?

 

[Zoltan_Gyimesi]

Hi Steve,

I suppose, you comapred an APPL type application.

What does it mean: "against the PYSAVE version of the same program"

Does it mean, that this "version" on an other Path Code or Save Location?

Is it a new custom application or a modified existing one?

Last question:

Had been some mods done more than once on this application?

Regards,

Zoltán

 

[MCCInet]

Hi Zoltan,

We have a PYSAVE location on our path code. There is a custom version of the program there and I am comparing it to a newer version of the program and making the same changes to it.

 

[MCCInet]

Oh, and the fields not syncing up are new ones added. However the exact same names were used when added.

 

[Zoltan_Gyimesi]

Hi Steve,

I suppose, you re-created these fields, controls that already exist on PYSAVE.
In this case generally VERC can not match these fieelds, controls on the two location.

I suppose, FDA assign internal next IDs to the controls and FDA use these internal IDs when ER refers one. I am almost sure in it, because you can place many controls onto the same form with the same attributtes and ER name.

Sorry, in this case the only way (that I know) is to move the ER lines between the two version with VERC and re-check all lines in FDA and correct / re-enter where it is necessary.

Regards,

Zoltán

 

[DBohner-(db)]

Just a little note about the ERC tool.

When it resolves the variable names - it resolves them against an ID number, not the actual name of the field. Thus many horrifying things can take place...

If you blindly merge - you may have the ER display one field, and actually use a different field...

ALWAYS GO BACK AND TOUCH EACH LINE OF MERGED CODE!

I am sure you can think of many reasons, now, why NOT to trust the merge process... always go back and touch every line after the merge!

Daniel

 

[Zoltan_Gyimesi]

Hi Daniel,

You are right!

Sometimes can be useful to re-map all merged Table I/O statement too.

Regards,

Zoltán

 

[Larry_Jones]

Ditto to Daniel's statement.

The Merge process is not just a joke - its downright dangerous in my opinion! Better to redo the customization using Compare utility.

 

[DBohner-(db)]

Thanks Zoltan!

It is more than helpful it is, usually, necessary don't trust what you see on the screen - remap it.

db

 

[MCCInet]

Hi Zoltan,

I don't know why everyone is talking about Merge - I am not doing that nor did I mention it. I am trying to manually move the lines in using VERC.

You recommend here to "move the lines between the two version with VERC" which it will not allow me to do because the names are not in sync. Hence my question.

I guess I have to manually rekey all of the lines, which I wastrying to avoid.

Thanks,

 

[MCCInet]

OK, I heard from JDE that in fact the VERC does use field identifiers to compare fields. It does not use the name of the field. In order to compare two different versions of a modified program, the new fields added to both would have to be added in the exact same order as the program being compared to.

In this position the only solution is to reenter the ER's for these fields. There is no way to modify the unique field identified.