Homepage › Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › IF data fetch produced multiple values
- This topic has 22 replies, 10 voices, and was last updated 11 years, 3 months ago by
Gary Atkinson.
-
CreatorTopic
-
December 9, 2008 at 8:00 pm #50504
lisa sater
ParticipantDoes anyone have any tcl that I can plug into the Xlate to get an idea of which of the 40 if statements is the one having an issue with producing multiple values? Thanks!
Lisa
-
CreatorTopic
-
AuthorReplies
-
-
December 9, 2008 at 8:48 pm #66356
Tom Rioux
ParticipantLisa,
One trick that I use is to put an echo statement in my xlate. I put it in near the top and if I see the results of the echo statement, then I push it down a little further in my xlate until I find the culprit.
Also, look at your IF statements and look for any that may not have the subfield designation on it (i.e. ..PID.#3.[0]). Those can be potential problems.
Hope this helps….
Tom Rioux
-
December 9, 2008 at 8:59 pm #66357
Max Drown (Infor)
ModeratorAlso, try copying the xlate to a test file and then removing pieces of the code until you narrow it down.
-- Max Drown (Infor)
-
December 9, 2008 at 9:35 pm #66358
Jim Kosloskey
ParticipantLisa,
I have used both of the techniques described by Tom and Max.
For echoing, I have a small proc that’s only function in life is to echo out what is in the inbound pane of the COPY Action. It has a switch to tell it to echo or not.
I use that a lot when I have complex nested ITERATEs and/or IFs. By having the switch, I can leave the proc in place and turn the switch off for normal execution and then when I need to make that next modification, I don’t need to remember where to lay my traps I just turn the switch back on at the appropriate places for the echoes I want.
The binary technique Max describes is made a little easier to deal with using the Insert File capability in the Xlate.
I think the ability to better cut and paste in Cloverleaf(R) 5.6 will make the binary technique easier to do as well.
email: jim.kosloskey@jim-kosloskey.com
-
December 9, 2008 at 9:40 pm #66359
Tom Rioux
ParticipantAnother way instead of removing code, if you are on 5.6, just go down the line and deactivate/reactivate your IF statements until you find the one that is the culprit. Then, once you have found it, reactivate it and make your corrections. No need for copying, pasting, inserting or removing anything…including echo’s
Hope this helps….
Tom Rioux
-
December 9, 2008 at 9:50 pm #66360
Chris Williams
ParticipantThat IF data fetch error is coming from insufficient granularity in your address for the given data. One notorious culprit that we see in our organization is the use of an ampersand in an address or name field as part of the text without considering that it is a separator character (e.g., A & W Root Beer. 4th & Main St, etc). You could also have a repeating field and just be specifying the entire field instead of the specific repetition.
-
December 9, 2008 at 10:01 pm #66361
Jim Kosloskey
ParticipantTom,
I like that new feature in 5.6 – just getting started playing with 5.6 so I forgot about that.
Anyway Lisa, lot’s of ways to narrow it down – but no magic bullet.
email: jim.kosloskey@jim-kosloskey.com
-
December 11, 2008 at 7:02 pm #66362
Max Drown (Infor)
ModeratorA note on “deactivating” if statement. I think when you deactive the IF and not the statements in the body of the IF, the statements are still executed. You have to deactive each statement within the IF body, too. I think …
-- Max Drown (Infor)
-
December 11, 2008 at 7:06 pm #66363
Tom Rioux
ParticipantI just tried to deactivate an IF statement. It grays out the IF statement along with all of the statements included with the IF.
Tom Rioux
-
December 11, 2008 at 7:18 pm #66364
Rob Abbott
KeymasterTom is correct. If you deactivate any node that has statements underneath (IF, iterate, etc) all the statements nested underneath are deactivated as well.
Rob Abbott
Director, Product Management - Infor Cloverleaf -
December 11, 2008 at 7:59 pm #66365
Max Drown (Infor)
ModeratorI know it shows as deactivated, but I think the statements in the body are still executed when a message flows through. I definitely could be wrong, but I think I ran into that problem awhile ago.
-- Max Drown (Infor)
-
December 11, 2008 at 8:41 pm #66366
Tom Rioux
ParticipantMax and Rob,
I just did a simple test. I had an IF node in an xlate with one statement underneath. When I deactivated the IF node, the statement below it did not get executed.
Hope this helps…
Tom Rioux
-
December 12, 2008 at 5:32 pm #66367
Rob Abbott
KeymasterMax Drown wrote:I know it shows as deactivated, but I think the statements in the body are still executed when a message flows through. I definitely could be wrong, but I think I ran into that problem awhile ago.
If you can reproduce this please let us know. That does not sound like it is working as designed.
Rob Abbott
Director, Product Management - Infor Cloverleaf -
December 15, 2008 at 7:00 pm #66368
Max Drown (Infor)
ModeratorI tried to reproduce it, but I can’t. Seems to be working fine. It might have been some weird situation or more likely I was mistaken.
-- Max Drown (Infor)
-
January 9, 2009 at 9:52 pm #66369
Femina Jaffer
ParticipantHello everyone,
I encountered the exact same error, and it happened to be exactly what Chris suggested – an AMPERSAND in the field (OBX 5). The questions is how to I fix this to avoid this error and make the IF work?
All I want to do is check if OBX 5 is NULL, IF SO THEN REMOVE THE ENTIRE OBX SEGMENT:
e.g. IF 1(0).1(0).1(%g1).OBX.00573.[0] eq @null
PATHCOPY -> 1(0).1(0).1(%g1).OBX
VALUE FOUND IN OBX5 – “for Ova & Parasite Exam “
Thank you,
Femina Jaffer
-
January 12, 2009 at 12:59 pm #66370
John Mercogliano
ParticipantFemina,
In an If statement you can narrow your search to
Code:
1(0).1(0).1(%g1).OBX.00573.[0].[0]
The extra .[0] takes into account the extra subfield that might exists.John Mercogliano
Sentara Healthcare
Hampton Roads, VA -
January 12, 2009 at 3:36 pm #66371
Femina Jaffer
ParticipantThank you, John. I will give this a try.
Thanks again.
Femina
-
September 4, 2012 at 4:12 pm #66372
Ian Morris
ParticipantJohn’s fix did not work for me. I’m looking through OBX segments for “PROCEDURE: ….. DESC:…..”. I’m doing it with a Xlate if-statement:
Code:(IF) 1(%g1).OBX(%s2).#5(0).[0] ct=PROCEDURE: && 1(%g1).OBX(%s2).#5(0).[0] ct=DESC:
The problem is that I get a “multiple values” error if I hit a segment with a “&” symbol.
Any tips on how to address this problem?
-
September 4, 2012 at 5:21 pm #66373
Gary Atkinson
Participantadd in pre-proc before translation and change the & to T. Run message through translation. In post-proc change T back to &. I use a table to make this easier to maintain. table of segs and fields to check for “&”
-
September 4, 2012 at 5:53 pm #66374
Ian Morris
ParticipantGary Atkinson wrote:add in pre-proc before translation and change the & to T.
-
September 4, 2012 at 6:09 pm #66375
Gary Atkinson
ParticipantYou could also try to go back to the vendor and tell them “hey your not following the standard” and see where that gets ya. I have been down that route before with no luck. I have attached the proc I have used before when I did xlate work, its arg driven (use at your own risk, yada yada yada…) 8)
GL
-
September 4, 2012 at 6:26 pm #66376
Ian Morris
ParticipantThat is helpful. Thank you for the proc.
-
September 4, 2012 at 6:33 pm #66377
Gary Atkinson
ParticipantNot a problem. Good Luck!
-
-
AuthorReplies
- The forum ‘Cloverleaf’ is closed to new topics and replies.