Weird ODBC Stage Behaviour

[abhilashnair]

I am accessing DB2 database using ODBC Enterprise stage. The query used inside it is running fine when fired on Database using Toad. But the same query when used inside ODBC stage, returns junk rows which are not there in the table. The junk rows returned are in addition to the valid rows and are at the end. The job fails due to these junk data as the data type mismatch happens.

Even in view data I can see those rows. They start appearing after a specified point. This changes in every job run;

Any suggestions?

[ray.wurlod]

How come everything you post is "weird"?

There's not enough information in your post to help you. Give examples of the query, and what you consider to be junk rows, and why.

You would expect weird results using a parallel ODBC stage in a server job, so why did you post a question about a parallel job in the server forum?! Now that's weird.

[abhilashnair]

How come everything you post is "weird"?

:D

Weird is something, I should not have used eh?

But then, I could not think of another word in this scenario, because my query works fine outside DataStage but not inside it

I say Junk rows because, those are not actual data. As I said, same query ran fine outside datastage and returned data as well.

In DataStage, apart from the valid rows, I am getting data which I am sure is not from the table. An instance is in one of the fields , I am getting a string of asterisks..something like '*********' . This particular field is a date field in the table. I have cross checked and found that there is no data like that in the table. Also it is a not nullable column...


The job aborts after couple of warnings and one fatal error

Warning: ODBC_Enterprise_1,0: Data string '*******' does not match format '%yyyy-%mm-%dd': an integer was expected to match tag %yyyy

But as I told my table has no data like that. I verified that by firing same quey in toad

Fatal: ODBC_Enterprise_1,0 [IBM(DataDirect OEM)][ODBC DB2 Wire Protocol] Socket Closed

[chulett]

The only time I've seen anything remotely like this, it turned out to be a database client software bug. What does your official support provider have to say on the topic?

[abhilashnair]

The only time I've seen anything remotely like this, it turned out to be a database client software bug. What does your official support provider have to say on the topic?

Not gone to them yet..Trying to debug from my end.

The source contains 817 rows. This error happens after 809 rows. But it has nothing to do with the data. The job runs successfully if I select less no of rows though

[MarkB]

Out of curiosity, have you tried one of the DB2 stages instead of the ODBC Enterprise stage to see if you get the same errors?

[abhilashnair]

Re worked the job and used DB2 API stage instead of ODBC Enterprise. It worked fine...Guess something was amiss in ODBC, since the same query and same metadata was used in DB2 API as well