Page 2 of 2

Posted: Tue Aug 30, 2005 7:34 am
by chulett
That's the "value of the row is" informational message I was speaking of that is posted along side any errors, not really an 'error' message, per se. :?

They are always truncated at a certain size.

Posted: Tue Aug 30, 2005 10:40 am
by logic
Hi,

Code: Select all

how many other sides are there in the job?
No there is no other link for update or any other stage.

Code: Select all

The error is occuring on the insert side I guess
I had earlier thought that this error might occur during the select statement or the insert and so tried to specify that it is occuring on the insert side. my bad.

The error message is truncated at a certain size. So I also think that this is an informational message and not really an error. Because in previous run the message was showing columns upto cw_chair and thats where i spent time investigating if something is wrong with the column at which the message was truncated. But was unable to see anything wrong. :?

nothing has changed since the time i have posted the message. and thats the whole point that insert statement is having 34 markers and there are 34 columns.
I have checked the derivation of all 34 columns.it is present and all columns are straight moves.
When i run the debugger i see all the values being passed to the out link with the same values as in the in link as expected. but still the warning persists.
Thanks,
Ash.

Posted: Thu Sep 22, 2005 2:05 pm
by logic
Hi,
This error is ocurring due to a CLOB column. Previously This problem was solved when I removed the CLOB column.
Now I have to incorporate that column. I am using DRS to extract and also to write the data. I defined the column as varchar 4000. But Rows are getting rejected with the error

Code: Select all

"Inserted Value too large for column, Row Rejected"
.
viewtopic.php?p=146582&highlight=#146582
I tried to double the 4000 value and kept doing so , at a point the "value too large error" stopped, but then i get the error

Code: Select all

"not all variables bound from job"
:? Number of Columns is 56.
Any way around this?
Thanks Ash.

Posted: Fri Sep 23, 2005 9:40 am
by aqtl
This is a bug of OCI Stage in DS 7.5.1. Here is the link for the information :

http://www.ascentialsoftware.com/eservi ... tches.html

Gook luck ...

Posted: Fri Sep 30, 2005 10:43 am
by srinagesh
Hi !

I seem to have hit the bug today.

I have a source table (Site Id, Site Name, ReferenceSiteName)

I have to look up to the table (ReferenceSiteId, ReferenceSiteName) on ReferenceSiteName and populate the Target table.

The lookup fails with the error "LoadDA_GTIL_GTISS_SITES..Trs_GtilGtissSites: ORA-01008: not all variables bound"

As a test, I put "1" against the ReferenceSiteId (and removed lookup on ReferenceSiteName) and ran the Job. It worked fine without any problem.

Any Suggestions (other than installation of patch; bcos it will take about 1 month for approvals to come thru) to resolve this issue

Regards
Nagesh

Posted: Fri Sep 30, 2005 11:10 am
by logic
Hi Nagesh,
Some thoughts.
If you are using a userdefined sql, then first try checking the sql. Also check for other clauses like Where etc if you are using any. If you have a generated sql and if any of the columns is a CLOB,then that might be part of the issue.
Ash.

Posted: Fri Sep 30, 2005 12:12 pm
by I_Server_Whale
Hi,

I think you have to download & install the patch for

Description:
Oracle OCI stage (ORAOCI9) incorrectly binds the lookup column values to the SQL statement which is being executed. This results in the Oracle database error "ORA-1008: Not all variables bound" [ECASE 73423].


You can download this patch from:



Code: Select all


http://www.ascential.com/eservice/pages/download/dsPatches.html
Hope that solves your issue,

Thanks,
Naveen.

Posted: Fri Sep 30, 2005 12:35 pm
by logic

Code: Select all

Any Suggestions (other than installation of patch; bcos it will take about 1 month for approvals to come thru) to resolve this issue 
I was thinking If Performance is a second priority , did you try using other stage than OCI?
ash.

Posted: Fri Sep 30, 2005 12:41 pm
by srinagesh
Thats a good idea.. I will try with ODBC and see if things work out.
Thanx a lot

cheers
nagesh