Skip to main content
Solved

BulkAttributeRenamer after SQLExecutor gives error

L

Dear FME'ers,

 

I have a question about the conflict resolution of SQLExecutors and FeatureReaders.

I found the issue when I was reading data from a PostgreSQL database. Some of the initiator's attribute names where the same as in the result of my SQL. Therefore I used the option 'conflict resolution'. This because I supposed that the data of the initiator is then overwritten by the data of the SQL script (for the attributes with conflicting names).

After that I tried to rename the output attributes with the help of a BulkAttributeRenamer but got an error. This is not the case when I set the conflict resolution to 'Use Initiator'. There is also no problem when I use a regular AttributeRenamer

 

If I'm obliged to remove all conflicting attributes then what is the use of the conflict resolution? Or is this a problem related to the BulkAttributeRenamer?

 

In attachment an example of my question with some extra info. I was able to recreate the issue by reading an Excel file with a FeatureReader:

 

Our FME version: 2019.1.3.0 (20191007 - Build 19642 - WIN64)

we use python 3.6+

 

Thanks in advance!

Kind Regards,

Louis Put

 

Best answer by markatsafe

@louisput Thanks for reporting this and for creating a simple reproduction workflow of the problem. The attribute conflict resolution of the FeatureReader should work as you described. We'll get this addressed.

View original
Did this help you find an answer to your question?

3 replies

M
Forum|alt.badge.img+2
  • markatsafe
  • Best Answer
  • December 18, 2019

@louisput Thanks for reporting this and for creating a simple reproduction workflow of the problem. The attribute conflict resolution of the FeatureReader should work as you described. We'll get this addressed.

erik_jan
Contributor
Forum|alt.badge.img+17
  • erik_janContributor
  • Contributor
  • December 18, 2019

A possible work-around could be using aliases in the SQL statement in the SQLExecutor, like:

Select attr1 as myfirstattribute

, attr2 as mysecondattribute

From table

This will rename the attributes from the database to myfirstattribute and mysecondattribute and allows you to avoid the conflicts.

 

Another work-around would be using the BulkAttributeRenamer before the SQLExecutor or FeatureReader to rename the source attributes and not the database attributes to avoid conflicts.

 

Hope this helps solving the issue.

L
  • louisput
  • Author
  • December 19, 2019
erik_jan wrote:

A possible work-around could be using aliases in the SQL statement in the SQLExecutor, like:

Select attr1 as myfirstattribute

, attr2 as mysecondattribute

From table

This will rename the attributes from the database to myfirstattribute and mysecondattribute and allows you to avoid the conflicts.

 

Another work-around would be using the BulkAttributeRenamer before the SQLExecutor or FeatureReader to rename the source attributes and not the database attributes to avoid conflicts.

 

Hope this helps solving the issue.

Thanks for the reply. I will rename the attributes of my initiator and remove conflicting attributes before the SQLExecutor. With the help aliases I will then set the SQL output attributes names.

Reply


Helpful Members This Week

Community Stats

30,912
Posts
117,125
Replies
38,714
Members

Latest FME

Terms & ConditionsCookie settings

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.