Parse Delimited Function B1300040

Chan Rana

Chan Rana

Legendary Poster
I am having an issue with the function B1300040 which i am using to process my flat file record(which is delimited by , or |) to retrieve fields(segments). From my research i ended up with finding that all String Parse functions designed by Oracle(in my TR) are having limitation that they return next non blank segments if your current segment is empty.
For e.g. if your record is
1000|String|||UOM
Function will run correctly for first two segments returning 1000 & String respectively for segment 0 & 1. For Segments 2 & 3 it will return UOM instead of blank.

I am followed up with Oracle and have got answer that there is no fix for this issue and function works as designed.

I am sure that there are many clients who process the flat file so want to know if they ever faced this issue and if they had to built a custom function for this or used TC to overcome this issue.

Any inputs are appreciated.

Chan
E1 8.12 TR 8.97.12 AS/400 DB2
 
Chan,
I see that bsfn uses the c-function, strtok (or jdeStrtok)...unfortunately, that c-function will not return 'empty' tokens. It will treat consecutive tokens as 1 token.

That bsfn will not work for you as written. As you suspected, you'll probably have to write a custom function or use TC (ugh!). Of course, there is always the possibility that another bsfn already exists that does what you need, although finding one could prove difficult.

The exercise of writing a strtok replacement would not be that difficult.

Good luck.
 
Jeremy,
Yes, the reason to post it here is i am surprised that there must be so many clients using the delimited flat file and i dont see any post so far related to this.
As for Oracle I got standard answer but if the function returns a wrong string for segment for me its a bug.

Does this conclude that all are using either a custom function or TC for flat file?.

Chan
 
To close the loop here is what i found a very easy workaround using the replace string function to replace all empty token strings.

Hope this helps somebody in future.

Chan
 
Hi Chan,

Just an input, as you asked for.
Sometimes I had used wrapper UBE technique over the TC UBE (as Peter mentioned), but sometimes it was not a real solution.
More times (at least 6+ times) I developed my Parser BSFN. I had much-more control and flexibility doing this job.
I suppose, this spared time for me instead experimenting with vanilla BSFNs - and I did the job in a NON TC UBE, having control over the input file location, based on POs (generally I have 3 POs, as - Folder name, File name, File Extension - making easier to set up it by the user (someteimes times-stamps in the name based on a custom file or so)), as an RI Data Structure, when it called indirectly.

Maybe I am a bit confused, over bier(s) - execuse me
cool.gif


That was my "input" - not more.

Regards,

Zoltán
P.S.: I use(d) similar technique to produce Output Flat Files instead of CSV Output or TC UBE.

Excuse me, not a help is this post - just a bit information from an other member.

Regards,

Zoltán
 
exactly same as zoltan, i have encountered this problem the first time I did a batch to read from a flat file, and since then I always build my own parsing BSFN.
I hate TCs because I have had really bad experiences in the past with it.
In my opinion, TCs are only to be used in simple One Shot Data Copies.
 
Hi Zoltan,

Could you please share the Custom Parser Code.

Thanks.
Version - JDE XE
 
Back
Top