DSXchange

Hi All,

I am getting the following warning:

ORA_CUSTOMER: When checking operator: The modify operator has a binding for the non-existent output field "BILLING".

My source stage is Oracle Enterprise and so is my target, through a copy stage. All the columns from source to target, through the copy stage, have valid derivations.

Any idea why this warning is being thrown?

Thanks in advance.

-Deepa

What is the source of the 'missing' column? a SQL ?

Yes it is a SQL. All columns are present in the SQL.

have you check column metadata is available for the column in stage you are putting query?

kamalshil wrote:have you check column metadata is available for the column in stage you are putting query?

I know it is an old post but I don't think it's necessary to open another for the same problem.

I am taking the data from a dataset. My question is what if I have Runtime Column Propagation checked for all job ? Metadata still needs to be present in that Modify stage ?

I am getting same error and I can't figure it out why.

Turn on $APT_PRINT_SCHEMAS for this job, it will show the actual schemas between each of the stages in the job and goes a long way into finding the sources of errors.

ArndW wrote:Turn on $APT_PRINT_SCHEMAS for this job, it will show the actual schemas between each of the stages in the job and goes a long way into finding the sources of errors. ...

Many thanks ArndW, for me that did the trick and helped me find where it was the problem. The variable name in my version is $OSH_PRINT_SCHEMAS but I wouldn't have found it without your help.

The variable name in my version is $OSH_PRINT_SCHEMAS as well, I just can't type very well....

I'm going to go ahead and continue this thread as well.

I'm getting the same error on a table coming from an sql server. I'm using an ODBC Connector stage to connect to the table and have loaded the table definition and can in fact see the columns and table data when I select 'view data'. The columns are in the output tab as well.

When I look in the Transformer Stage I see all of he columns there, so all looks good.

Still, when I run the job I get:

'When checking operator: The modify operator has a binding for the non-existent output field "AAA".' - on the ODBC Connector Stage and

'error when checking operator: Could not find input field "AAA"' - on the Transformer Stage

How am I able to view columns and data in the ODBC Connector stage, yet I receive these errors when I run the job?

Thanks!

iq_etl - did you add the environment variable as suggested in this thread and see exactly what columns are being used?

If you mean setting $OSH_PRINT_SCHEMAS to 'True', then yes and the error message tells me the name of the column (there are 5) and just used 'AAA' as an example name.

Just to clarify, the output contains the schemas for each stage in the job. In the input link to the transform stage the schema contains a column name, i.e. "AAA", which is then given in the error message? If yes, please cut-and-paste the schema and the error message to the thread.

Sure. In my parallel job, I have an input ODBC stage 'odbc_DBO_COGNOSBUDGETS' which reads rows from a table on an SQL server and goes to a Transformer stage called 'xfm_BUDGETS'. In the below messages, 'ID' is obviously a column.

Here are the error messages:
Warning (type): odbc_DBO_COGNOSBUDGETS: When checking operator: The modify operator has a binding for the non-existent output field "ID".

Fatal (type): xfm_BUDGETS: Error when checking operator: Could not find input field "ID".

Again column "ID" is in the table definition, can be viewed with data in the ODBC input stage, and is in the Transformer stage.

EDIT: When I set 'Fail on size mismatch' to 'No' for that SQL server input table I no longer receive those errors. Looks like that's the way to go.

That was one half of the request, now please cut-and-paste the schema going into your modify stage as shown in the log file from the output of $OSH_PRINT_SCHEMAS.

I am fairly certain that the column -isn't- in the input schema. The source column metadata for ID and what you've declared don't match, so the column wasn't taken into the schema with your previous setting. The correct choice is to make the data types and sizes match.

I agree, the correct choice is to have the data types and sizes match. Unfortunately, this table is owned by an external client and we have to work with what they have.

On the upside, this is a one time load as future data will be put on a table that matches ours.

At any rate, here's the schema. It looks to have all of the columns (let me know if it isn't what you wanted to see):

DSDisplayWidth={ID=11, code1=11, code2=11, code3=11, fiscalYear12_13=22, fiscalYear13_14=22},
DSSQLType={ID=4, code1=4, code2=4, code3=4, fiscalYear12_13=6, fiscalYear13_14=6},
DSSQLPrecision={ID=10, code1=10, code2=10, code3=10, fiscalYear12_13=53, fiscalYear13_14=53},
DSSchema='record
(
ID\:int32\;
code1\:nullable int32\;
code2\:nullable int32\;
code3\:nullable int32\;
fiscalYear12_13\:nullable sfloat\;
fiscalYear13_14\:nullable sfloat\;
)'
}'