Skip to main content
  • EN

I'm using FME Workbench 2017.1.

I have a reader connection with multiple features (tables) being read from it. One of the features (let's call it Users for example) uses a SELECT STATEMENT option to get additional information (I can run and test the select, it's valid and it works). Right before FME uses that select statement to "obtain features for feature type", I'll get a bunch of warning messages in the log output like this:

WARN | Oracle Reader: Column 'ID' specified on Feature Type but does not exist in table 'SCHEMA_NAME.USERS' and will be ignored

This will happen for all columns of Users. I can verify that the columns exist in my source table.

Even with these warnings, the records of Users will be read and written to their new destination. However, every other feature type that needs to be read/written after Users (say Logins, Favourites, Friends, whatever) will give me the same warning message for each of their columns and will not write anything to the new destination.

As soon as I remove the SELECT STATEMENT from Users, everything works fine: no warning messages, and all feature types (tables) get read and written.

Does anyone know what's going on? The issue seems to be with the SELECT STATEMENT. Even if I change it from a somewhat complicated join to just "SELECT * FROM USERS" this same behaviour happens.

Any help would be appreciated.

UPDATE: It appears that as soon as a SELECT STATEMENT is entered, FME will ignore the originally retrieved attributes of the feature type and try to use the select statement. That's fine. But all other feature types of that reader connection now assume there is a SELECT STATEMENT as well, and because they don't have one, they are ignored in the workspace.

The feature_type has a number of attributes defined, that do not match the output of the select statement. Therefor the attributes retrieved from the select statement are ignored.

In your case I would use a SQLCreator transformer instead of a select statement replacing the table.

That allows you to specify a select statement and the attributes to retrieve.

The feature_type has a number of attributes defined, that do not match the output of the select statement. Therefor the attributes retrieved from the select statement are ignored.

In your case I would use a SQLCreator transformer instead of a select statement replacing the table.

That allows you to specify a select statement and the attributes to retrieve.

Even if I add a SELECT STATEMENT of just:

 

 

SELECT * FROM Users

 

 

I still get this issue. So even though I tell it to output all the User columns, and the feature type knows about them all, it still issues me warnings and causes later feature types to not write their data.

 

 

Even if I add a SELECT STATEMENT of just:

 

 

SELECT * FROM Users

 

 

I still get this issue. So even though I tell it to output all the User columns, and the feature type knows about them all, it still issues me warnings and causes later feature types to not write their data.

 

 

Yes, I was able to reproduce this, using FME 2018.

 

Time to send a message to support@safe.com.

 

Even with the warning, the attributes were available in the output.

 

Not sure if the warning is a bug.

 

This looks like a bug. It's two fold (although the first "bug" is more so a red herring).

1. When you use a SELECT STATEMENT, you will receive the warnings I mentioned because FME does not know what attributes will actually be exposed yet, even though your reader object on the canvas has information about attributes. That's why after the warnings FME runs your SELECT to figure out what the attributes really are. FYI even new columns that you are explicitly selecting that are not part of the original table definition will be made available in the FME feature object, so you can access them via Python without needing an AttributeExposer Transformer.

2. Once one feature type of a particular database connection uses a SELECT STATEMENT, FME assumes that all other readers of that connection use one as well. So you will see warnings like I mentioned for each of your tables/columns. Then, FME will try to run the SELECT STATEMENT for each feature, but because you haven't supplied one, nothing will run, so that whole feature is skipped. The workaround is supply a basic "SELECT * FROM YOUR_TABLE" into all the features.

The feature_type has a number of attributes defined, that do not match the output of the select statement. Therefor the attributes retrieved from the select statement are ignored.

In your case I would use a SQLCreator transformer instead of a select statement replacing the table.

That allows you to specify a select statement and the attributes to retrieve.

Thanks for your time, Erik. I've submitted a bug to Safe.

 

 

Hi @mrdanalvarez and @erik_jan, I have been able to reproduce the issue you're describing and have filed a problem report with our development team. I'll update here once the issue has been resolved. Thank you for bringing this to our attention.

Reply


Community Stats

30,470
Posts
115,705
Replies
38,288
Members
Terms & ConditionsCookie 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.