DSXchange

prem,

This is a wild guess. Is it possible that the data in the column has a character that you have specified as the column delimiter for the flat file?

Hope this helps,
Tony

prem wrote:I got the following error message while running a job that extracts from a SAP source table using ABAP R/3 Extractor stage.The target is a sequential file,with a single column hash file acting as a reference for selection of rows from input.

I am getting the same, this is the log message:

==========
Project:CorusITB_Dev (corus)
Job name:Inv_Test
Event #:25
Timestamp:19/11/2004 11:52:53
Event type:Fatal
User:phibbs
Message:
Inv_Test..Transformer_5: Mismatch in number of column between data and link
At row 2, link "Supplier_Extract", while processing column "BKPF_AWKEY"
Mismatch in number of column between data and link
==========
BKPF.AWKEY is the first field in the query. It is interesting that it is failing at row 2! The target sequential file is set to write the first line as column names, but this shouldn't affect the row numbering on the input to the transformer stage.

Hi Guys,

Try to change the Length and Display values.. I think it will work.

Srini
BB

DataStageCnu wrote:Hi Guys,
Try to change the Length and Display values.. I think it will work.
Srini
BB

I tried that, no luck. The odd thing is that removing the second table gets rid of the problem, even though the field that it complains about is in the first table. Maybe my join key is wrong, and this error is some cryptic way of saying that the primary key is not unique.

Hi,

I assume that you have cheked your idocs and confirmed that they look okay.
Also that you haven't moved from one SAP client to another after you have imported our metadata.

Another thing is that when you extract the metadata for decimal fields, then DS sets them 1 to long - Dec 10 will become Char 11 etc.

br
Tom

We had exactly the same issue with large number of source rows in a SAP table. The reason was a timeout done by SAP. You have to use a backgroud user instead of a dialog user and set timeout value to large enough.

This happened to me and I found that it was being caused by the code that I had generated being changed (either directly through SAP - or by someone else creating or editing a job with the same name through Datastage). If you go into the ABAP extract stage ensure that the ABAP Program ID is unique to your Datastage job and then generate just before you execute your job.

If the code has been generated by Datastage and then elsewhere the code is regenerated for a different set of columns, then when you come to run the original Datastage job, it will use the code that was generated by the other system, but then try to map the retrieved columns onto the set of columns defined, and produce the above error.

Hope that helps

Tim