Why does the "enable/disable readers/writers" form not have any visible effect when I uncheck/check the boxes in the form and click okay?
Why when I copy and paste readers from two open .fmw files do those readers become misnamed and unusable?
Page 1 / 1
*from one open fmw translation to another fmw translation *
Random thoughts:
- Are your FME Translations created in different versions of FME Desktop? Some old versions of formats have compatibility issues in a fresh new Workspace as they were originally designed for a specific version. Thus if you copy from a old workspace to a new workspace you may have issues.
- Are you opening the *.fmw fies in different versions of FME Desktop? Some formats aren't supported in earlier versions of FME or in 64-bit environments.
Can you please be more specific, copying and pasting readers usually work as expected from my point of view. Also, take note of the distinction between Readers and Feature Types, as mentioned by 1SpatialKathy above.
Which version(s) of FME are you using, and which Readers? Also, please give us a concrete example of how your Readers are renamed, that might help us give you a better answer.
David
@1SpatialKathy :
*The FME translations were both created using the same version of FME Desktop.
*The fmw files are opened in the same version of FME Desktop
@David R.:
It's strange. They get renamed as other writers that are in the destination fmw document.
For instance I want to copy writers x, y, and z from fmw1 to fmw2. (I am simply selecting readers in the canvas and right clicking>copy). fmw2 has reader a, b and c. I right click>paste in the canvas. In the navigator, after I have pasted x, y and z, they will be renamed as duplicates of a, b, and c. I will have two sets of a, b, and c. I've just decided to avoid the issue altogether and not do any copy and pasting.
That does indeed sound strange. I do suspect that there is a snag somewhere that has been overlooked, causing this behaviour.
In your place, I would send a copy of both workspaces to reproduce this issue to support@safe.com, they should be able to tell you what's wrong.
David
Realizing that this trail is now very cold, I would still like to advise that, after all these years, we've caught the culprit code and it is fixed in the FME 2017.1 code base (too late to put it into 2017.0). I apologize for this. Our old code was trying to be very clever and could get into this state in the correct (but not all!) situations.