INSERT useing Oracle stage fails - Special characters

Post questions here relative to DataStage Enterprise/PX Edition for such areas as Parallel job design, Parallel datasets, BuildOps, Wrappers, etc.

Moderators: chulett, rschirm, roy

algfr
Participant
Posts: 106
Joined: Fri Sep 09, 2005 7:42 am

INSERT useing Oracle stage fails - Special characters

Post by algfr »

Hi guys,

I have an issue with an Oracle stage to load a table.

At some point my job crashes saying it cannot insert a record (can't tell which one javascript:emoticon(':evil:')).

I figured it's cause by a varchar field that can contain all sorts of bad characters (commas, slashes, percents, etc).

My question is ? How to force DS to escape all characters in the INSERT STATEMENT it generates (ORCHESTRATE.XXX) ? This is quite annoying.

Thanks a lot
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Nothing you've listed are "bad characters". How about some details? Tell us what stage and options there you are using and post the actual warnings / errors from your log.
-craig

"You can never have too many knives" -- Logan Nine Fingers
algfr
Participant
Posts: 106
Joined: Fri Sep 09, 2005 7:42 am

Post by algfr »

Hi Craig,

The thing is that I cannot probe the output so that I can retrieve a good example. I just know that if I insert a constant string instead of the initial input, the job gets through.

I only trim an input field from DB2-AS400 and load it through a SCD stage. It crashes when getting into the ORA stage which upsert the table. I get the following error in the log :

ora_DWH_DIM_PRD_new,0: Unable to insert a record into the table. The error type is IIS-DSEE-TOUP-00022.

Otherwise, do you have an efficient way to see exactly what row fails ?
algfr
Participant
Posts: 106
Joined: Fri Sep 09, 2005 7:42 am

Post by algfr »

In my design I use reject tables but in this case this does not work. I assume this is because the INSERT STATEMENT sent to Oracle is invalid.
chulett
Charter Member
Charter Member
Posts: 43085
Joined: Tue Nov 12, 2002 4:34 pm
Location: Denver, CO

Post by chulett »

Too many assumptions here at the moment. What stage exactly - Oracle Enterprise? And are you doing an Upsert or a Load or ??? Details, please.
-craig

"You can never have too many knives" -- Logan Nine Fingers
tippy1
Premium Member
Premium Member
Posts: 4
Joined: Fri Feb 11, 2005 7:18 pm

Post by tippy1 »

The message your are getting "unable to insert row" is generic and will not give you the exact reason. Do the following

Try inserting the row into the table using SQL Plus or Toad and see if error occurs. If this is sucessful then have your DBA look at tablespaces
and other database reason that might cause a row to be rejected even though the data is clean.
algfr
Participant
Posts: 106
Joined: Fri Sep 09, 2005 7:42 am

Post by algfr »

Craig :

I'm upserting a table using an Oracle Enterprise.

Tippy:

This is a great idea but I don't know how to "capture" the wrong record.
miwinter
Participant
Posts: 396
Joined: Thu Jun 22, 2006 7:00 am
Location: England, UK

Post by miwinter »

Couldn't you try the entire data through the method suggested and see if the warning/error returned from that shows you which is the problem record?
Mark Winter
<i>Nothing appeases a troubled mind more than <b>good</b> music</i>
algfr
Participant
Posts: 106
Joined: Fri Sep 09, 2005 7:42 am

Post by algfr »

Sorry, do you mean by extracting the output to a SEQ file and create INSERT STATEMENTS out of it ?
miwinter
Participant
Posts: 396
Joined: Thu Jun 22, 2006 7:00 am
Location: England, UK

Post by miwinter »

Yes, exactly, obviously not so feasible if you are dealing with any kind of volume, but I haven't seen that mentioned so far.

On the other side of it, though I'm not yet at v8, I heard that a reference was provided for error messages etc these days. Is "IIS-DSEE-TOUP-00022" not listed in that anywhere?
Mark Winter
<i>Nothing appeases a troubled mind more than <b>good</b> music</i>
algfr
Participant
Posts: 106
Joined: Fri Sep 09, 2005 7:42 am

Post by algfr »

Ok I did it, a few records cannot be inserted using TOAD loader tool.

1) Some records exceed the max limit (though i KNOW it can't be). I suspec some special chars to be badly transmitted (soem become question marks ??), thus extending the string. Can this be solved ? I tried changing the NLS set but it did nothing

2) Some records contains semicolons. Can these be replaced , using the Convert function ?

Thanks for helping

Arnaud
ArndW
Participant
Posts: 16318
Joined: Tue Nov 16, 2004 9:08 am
Location: Germany
Contact:

Post by ArndW »

That would not be a hex or binary viewer. The goal is to get the numeric representation of what is in that character.
algfr
Participant
Posts: 106
Joined: Fri Sep 09, 2005 7:42 am

Post by algfr »

ArndW wrote:That would not be a hex or binary viewer. The goal is to get the numeric representation of what is in that character. ...
Should I load the data into a dataset and open it afterwards ?
ArndW
Participant
Posts: 16318
Joined: Tue Nov 16, 2004 9:08 am
Location: Germany
Contact:

Post by ArndW »

How about taking this step-by-step. Modify your job to put an output link from your Oracle stage directly to a flat file and in the Oracle stage options mark "Output reject records" as "true".
After the run do a "cat -v YourRejectFileName.txt" to get both the SQL error code and the data contents with undisplayable characters shown as octal or control codes.
algfr
Participant
Posts: 106
Joined: Fri Sep 09, 2005 7:42 am

Post by algfr »

ArndW wrote:How about taking this step-by-step. Modify your job to put an output link from your Oracle stage directly to a flat file and in the Oracle stage options mark "Output reject records" as "true".
After the run do a "cat -v YourRejectFileName.txt" to get both the SQL error code and the data contents with undisplayable characters shown as octal or control codes.
Hi again ArndW :-)

I already tried using a reject link out of the Oracle stage but it does not work.

It seems DS is not able to identify the row and treat it just as if the INSERT STATEMENT used is wrong, this, because of the "weird" data...

Sorry I didn't understand correctly what you said.
Post Reply