FILTER logic getting jumbled when GENERATED...

Question

Environment:
OWB10g Client on Windows XP Professional
Repository - 9.2.0.4 on UNIX (AIX 5.2)
Target - 9.2.0.4 on UNIX (AIX 5.2)
I have a FILTER operator with the following in it:
( INOUTGRP1.ORDER_TYPE_PDDCTO = 'RX' And trunc ( INOUTGRP1.TRANSACTION_DT_PDTRDJ ) = trunc ( sysdate ) And trunc ( INOUTGRP1.FP_NEED_DT ) <= trunc ( INOUTGRP1.REQUEST_DT_PDDRQJ ) ) Or ( INOUTGRP1.LINE_TYPE_PDLNTY IN ( 'S','DM' ) And INOUTGRP1.STOCKING_TYPE_IBSTKT = 'P' And INOUTGRP1.UNITS_OPEN_PDUOPN > 0 And INOUTGRP1.ORDER_TYPE_PDDCTO = 'O3' And trunc ( INOUTGRP1.SCHED_PICK_DT_PDPDDJ ) < trunc ( sysdate ) )
It is an 'OR' between two separate sets of logic.
When the mapping is Generated the above code comes out like this:
WHERE -- ( = )
AND
-- ( = )
AND
-- -- -- -- -- -- -- -- -- ( ( = 'RX' And trunc ( ) = trunc ( sysdate ) And trunc ( ) <= trunc ( ) ) Or ( IN ( 'S' , 'DM' ) And = 'P' And > 0 And = 'O3' And trunc ( ) < trunc ( sysdate ) ) )
Can someone please tell me where in the %#^#* OWB is getting the above logic to translate my FILTER into the above gibberish?
This produces a 'PL/SQL: ORA-00936: missing expression' error on that line when I try to deploy it.
Also, on a related note that I saw a thread on earlier but can't find now, how do I get the FILTER operator to retain my CR/LF in the expanded expression of the filter?
The tag at the bottom of the expression window, where it shows the Line and Column numbers, shows WINDOWS:CR/LF which I thought I had read would retain the CR/LF's I put in the expression to make it easier to read rather than having to scroll to the right 27 miles.
Deep breath.
Deep breath.
Deep breath.
Ommmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.
Ommmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmmm.
I'm OK now.
Any help is greatly appreciated. ;-)>
Gary

Answer 1

Good morning Gary,
I remember we had the CR/LF discussion earlier, maybe it's 10g that wrecks it, got 9.2.0.4 here which works flawlessly in that sense.
Got 10g on my laptop (of course not with me right now) but basically the only thing that bugs me there is some nasty behaviour of not showing the entire 'picture' of a mapping any more after there have been some popups (like context or property menu) in the front.
Tip: if you want to show code in a thread use [ code] and /code] to mark it (in lowercase, without the space after the [, otherwise it would not show), e.g.:[code]
( INOUTGRP1.ORDER_TYPE_PDDCTO = 'RX' And trunc ( INOUTGRP1.TRANSACTION_DT_PDTRDJ ) = trunc ( sysdate ) And trunc ( INOUTGRP1.FP_NEED_DT ) <= trunc ( INOUTGRP1.REQUEST_DT_PDDRQJ ) ) Or ( INOUTGRP1.LINE_TYPE_PDLNTY IN ( 'S','DM' ) And INOUTGRP1.STOCKING_TYPE_IBSTKT = 'P' And INOUTGRP1.UNITS_OPEN_PDUOPN > 0 And INOUTGRP1.ORDER_TYPE_PDDCTO = 'O3' And trunc ( INOUTGRP1.SCHED_PICK_DT_PDPDDJ ) < trunc ( sysdate ) )
I was about to ask you what happens if you apply this code without any CR/LF in it, but I guess you've tried that?
Could be the OR is the culprit here. As a workaround maybe you want to try out some Boolean algebra to get rid of the OR. If memory serves me well:
(A.B)+(C.D) equals
NOT(NOT((A.B)+(C.D))) equals
NOT(NOT(A.B).NOT(C.D))
hence NOT(
NOT( INOUTGRP1.ORDER_TYPE_PDDCTO                   = 'RX'
  AND TRUNC ( INOUTGRP1.TRANSACTION_DT_PDTRDJ ) = TRUNC ( SYSDATE )
  AND TRUNC ( INOUTGRP1.FP_NEED_DT )           <= TRUNC ( INOUTGRP1.REQUEST_DT_PDDRQJ )
AND
NOT( INOUTGRP1.LINE_TYPE_PDLNTY IN ( 'S','DM' )
  AND INOUTGRP1.STOCKING_TYPE_IBSTKT = 'P'
  AND INOUTGRP1.UNITS_OPEN_PDUOPN > 0
  AND INOUTGRP1.ORDER_TYPE_PDDCTO = 'O3'
  AND TRUNC ( INOUTGRP1.SCHED_PICK_DT_PDPDDJ ) < TRUNC ( SYSDATE )
)An other option would be to use an expression operator to build a status 'column', and in this expression you build the filter logic with a case statement. Next, in the filter you use the status input to filter records.
Hopefully one of Oracle's own OWB-guys will be looking at this forum soon (if I use JP Dijcks as benchmark, they haven't since 28th of January) and give an answer on whether your noticed behaviour is a bug.
Good luck, Patrick