Skip to main content
Question

Date is being set to null with AttributeRenamer

sdepriest
Contributor
Forum|alt.badge.img+9
Does an AttributeRenamer not handle attributes with a Date data type very well?

 

 

 

I have a DATECREATED attribute on an SDE table.  The SDE table, Dampers, is the source data set and destination data set (both are using the ESRI ARCSDE30 format).  I’m updating some fields in the Dampers table by getting values using a joiner from another SQL Server table.  I have a DATEMODIFIED attribute that I’m setting with a TimeStamper field.  So I’m using the fme_db_operation = UPDATE in an AttributeRenamer.

 

 

 

And I don’t want the DATECREATED attribute value to change. The format is YYYYMMDD.  But it’s being set to null when I run the translation.

 

 

 

I’ve been trying a combination of things and can’t seem to get the DATECREATED attribute to save its value.  I've used the Feature Inspector to step through and the attribute disappears after the AttributeRenamer.

 

 

I must be going at this in the wrong way.  How do I keep an attribute value the same when i'm updating other attributes?

 

15 replies

david_r
Celebrity
  • david_rCelebrity
  • April 11, 2013
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
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 11, 2013
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.

 

david_r
Celebrity
  • david_rCelebrity
  • April 11, 2013
Hi,

 

 

I would recommend you use two different writers in this case, on for INSERT (with DATECREATED) and one for UPDATE (without DATECREATED).

 

 

David
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 11, 2013
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
M
Forum|alt.badge.img+2
  • mark_f
  • April 11, 2013
Think David was suggesting two writers rather than two duplicate Feature Types.
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 11, 2013
, thanks for the clarification.  i'll give that a whirl.

 

 

Sarah
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 11, 2013
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
david_r
Celebrity
  • david_rCelebrity
  • April 12, 2013
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
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 12, 2013
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
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 12, 2013
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
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 12, 2013
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
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 12, 2013
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
david_r
Celebrity
  • david_rCelebrity
  • April 13, 2013
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

 

 

M
Forum|alt.badge.img+2
  • mark_f
  • April 14, 2013
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.
sdepriest
Contributor
Forum|alt.badge.img+9
  • sdepriestContributor
  • Author
  • Contributor
  • April 16, 2013
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

Reply


Helpful Members This Week

Community Stats

31,457
Posts
119,244
Replies
39,075
Members

Latest FME

Terms & ConditionsCookie settingsAccessibility statement

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.