Hi,
you can delete all the attributes from the writer that you want left unchanged, as only the attributes present on the writer feature is modified.
So you could try to remove the attribute DATECREATED from your output feature type.
David
Well I am using the DATECREATED attribute in my Insert new Damper stream, so i can't really delete the attribute from the output feature type...unless I bring in the same feature type again? one for the update stream, one for the insert stream? Currently both streams are connected to the single output feature type.
Hi,
I would recommend you use two different writers in this case, on for INSERT (with DATECREATED) and one for UPDATE (without DATECREATED).
David
David, I chose to duplicate my destination feature type, and it was named with a "00" at the end. So I have a destination feature type of T_DAMPER for the INSERT & T_DAMPER00 for the UPDATE stream. When I run the translation the T_DAMPER00 feature type does not exist. And it seems to try to create a new table named T_DAMPER00. I tried to name it the same as the other, but it always goes back to T_DAMPER00. I'm tryign to process the updates and inserts with the same translation. I don't want to maintain two different translations...Other ideas? or can I somehow fake FME out?
Sarah
Think David was suggesting two writers rather than two duplicate Feature Types.
, thanks for the clarification. i'll give that a whirl.
Sarah
David and ,
That seemed to work. I added a 2nd writer with the same feature type, removed the attributes I didn't need from that feature type.
But I still encountered a bit of weirdness...
DATECREATED was one of the attributes I wanted left untouched after the translation finished. It's a date datatype.
When I added DATECREATED to the Old Attribute column of the AttributeRenamer and left the New Attribute column blank (deleting the attribute), the writer still changed the DATECREATED attribute to NULL.
When I removed DATECREATED from the AttributeRenamer entirely, the writer didn't touch the attribute and the value remained.
Strange thing is, I did the same thing to the CREATIONUSER attribute, and the writer did not change the CREATIONUSER value when it was in the AttributeRenamer. CREATIONUSER is a character field.
So does an AttributeRenamer have trouble with attributes of a date data type?
Sarah
Hi Sarah,
inside the workspace, all date values are treated as strings (as far as I know), so the AttributeRenamer should have no particular problem with these.
Regarding the updates of attributes: as you noticed, there is an important difference between deleting an attribute from the data flow compared to removing it from an output feature in update mode.
Could you perhaps post a screenshot of your AttributeRenamer?
David
David, got a suggestion for a website where i can upload a JPG of my AttributeRenamer? I was hoping i could just upload it directly from my machine, but i see I have to point to a picture on the web. Sarah
Ok, I remembered I have a Picasa Web Album. Hope this works. Here is the Attribute Renamer where I removed the DATECREATED & CREATIONUSER attributes.
(not sure web link works, all i see is a box with red X in it..but submit anyway to see if it works)
Sarah
that didn't seem to work...trying the "embed" link.
i don't think that worked...trying the link.
https://picasaweb.google.com/lh/photo/jhWUwPuhyHyG3_eIVVFwQ9MTjNZETYmyPJy0liipFm0?feat=directlink
that might work.
Sarah
Here is a picture of the AttributeRenamer added in. this is how i set it up originally. and a null value in DATECREATED would be the result. But CREATIONUSER would stay the same as expected.
https://picasaweb.google.com/lh/photo/nZIgvvpNvDkbDLIgGDvdCtMTjNZETYmyPJy0liipFm0?feat=directlink
Hi Sarah,
i see no apparent reason for the differences in behaviour you describe. Have you tried setting an
inspection point before and after the AttributeRenamer to see what is going?
Inspection points are a fantastic way to debug these types of issues, I heartily recommend reading up on them! :-)
David
What David says! Just a tip for future ... There is a BulkAttributeRenamer transformer which allow renaming of attributes to all upper case. Just in case you hadn't seen it.
David, Yes I agree. I don't see why it would do this. I have opened a ticket with support on this and I sent them my translation and sample source data. I have not heard back from them yet.
Yes I have used the Feature Inspector to look at the data before and after the ATtributeRenamer and still saw the behavior. I will post the solution once tech support and I work it out.
, yes I have found the BulkAttributeRenamer to change the case to all upper case. Love it! I believe I added one while i was testing and it didn't seem to make a difference...Again, once tech support finds a cause i'll post back.
Sarah
