Not that I know of. But then I'm a PowerCenter guy, the platform (Developer, DIS, and so on) is not my area of expertise.
What version of the Oracle(?) client do you have installed on your Informatica server?
What's the DB server version?
Could it be that someone has changed the flat file target definition resp. the physical / logical data object / the write mapping for the flat file?
Maybe there's some post-session success command which processes and changes this target file?
the oracle client is a linux x86 64bit 188.8.131.52
I am the only developer on the team, sole owner of the workflows and mappings, sources, and targets..
no post session processing touching the file..
sorry mispoke on the target, its a flatfile 1 column nstring(100000) and it is actually loading 3 rows to the target, but cutting them off as follows...
source brings in 3 strings .. the first 2 are 12000 characters, the 3rd is < 12000 (clob is chopped into 3 pieces in an oracle sp)
the source qualifier has it defined as text(15000) to make sure it holds each row, next expression is string(100000)
here is where it gets weird,
the first row comes in, gets cut off at 3750 and hits the target with the beginning of the string to 3750, then the next section of 3750 of that first string hits the target, then the remaining.. 3 rows on the flat file representing the 1 record that it brought in from the source.. not 2 rows of 12000 each and a 3rd row with the remainder..
target is flatfile ... 1 column nstring(100000)
again this is exact code as in version 9, I migrated the code to our informatica 10 environment and immediately saw this behavior..
What is the Oracle data type used for these strings?
it is Clob datatype...
3 rows in the table
1 row comes in, but that clob is getting split and loaded to the flat file
2 rows are missing completely on the file.. so I am not sure why those rows are getting ignored.. no filters, its a straight pull..
thanks for your help on this.. really appreciate it
Is the CLOB value extracted to PowerCenter as a TEXT or STRING attribute? Meaning the data type in the source definition. If I understand your earlier posts correctly, it's String, right?
Do you use any SQL override in the mapping or in the session?
source object is defined as an oracle table with clob(15000) -> SQ
SQ (not overriden) has that column as text(15000) -> expression
expression as text(15000)
Could you please try changing the data type of the CLOB from Text to String in the Source Qualifier (not the source definition)? I very dimly seem to recall having read something like this many many years ago.
Informatica 9 allowed the clob in from the source as size 12000 and processed it as is.. Informatica 10 seems to have a 4000 character limit (closer to 3750) and truncates it either at the source or the flatfile target. We have a open case with Informatica and sent them the source data and the target file that gets created.. they are replicating it now
I will let you know how that shakes out
The information about the lengths makes me suspect that there may be a problem with the code page of the Oracle connection you're using. Maybe the DBMS runs in UTF-8 and the connection is set to ISO 8859-15? Or vice versa? That might explain this strange behaviour.
Thanks for the update.
I notice that 3750 is one quarter of 15000. Are you possibly running in ASCII mode but reading from a UTF-32 source?
To me this has the smell of code page problems, as Nico suggested. Make sure your integration service is set up to run in Unicode mode (something that could easily have changed between your v9 and v10 installations) and make sure all the source and target codepages match what is actually there.
I am facing same issue.What was the resolution