| Author |
Message
|
| special_agent_Queue |
 Posted: Mon Oct 02, 2006 12:13 pm Post subject: Create nextsibling question/issue |
 |
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
I have a loop. Within this loop, I am using the statement CREATE NEXTSIBLING OF Pointer TYPE NameValue NAME EvalFName VALUE FIELDVALUE(Pointer).
Pointer points to an element.
The statement appears to be creating these new fields as attributes of the parent element, rather than as elements.
Has anyone experienced this, or have any idea why this is happening?
I'm working with v6 of the toolkit and broker. Here's a piece of the input msg, relevant code, and output msg.
Input Message:
<Claim><clm:fileNumber/>
<clm:lossDate>2006-09-11</clm:lossDate>
<clm:lossTime>12:00:00</clm:lossTime>
<clm:ServiceProviderRole>
...
</clm:ServiceProviderRole>
<clm:lossType/>
<clm:catCode/>
<clm:excludeCode/>
<clm:amountPaid/>
| Code: |
CREATE PROCEDURE AddPrefixes(IN StartPtr REFERENCE, IN Prefix CHAR, IN GoToChildren BOOLEAN, IN GoToSibling BOOLEAN)
BEGIN
DECLARE Pointer REFERENCE TO StartPtr;
DECLARE Pre CHAR;
DECLARE Children BOOLEAN;
DECLARE Sib BOOLEAN;
SET Pre = Prefix;
SET Children = GoToChildren;
SET Sib = GoToSibling;
DECLARE KeepGoing BOOLEAN true;
DECLARE FName CHARACTER;
DECLARE EvalFname CHARACTER;
WHILE LASTMOVE(Pointer) AND KeepGoing DO
SET FName = FIELDNAME(Pointer);
SET EvalFname = Pre || FName;
CREATE NEXTSIBLING OF Pointer TYPE NameValue NAME EvalFname
VALUE FIELDVALUE(Pointer);
DECLARE TempPointer REFERENCE TO Pointer;
IF Children THEN
MOVE Pointer FIRSTCHILD;
IF LASTMOVE(Pointer) THEN
CALL AddPrefixes(Pointer,Pre,Children,true);
END IF;
END IF;
MOVE Pointer TO TempPointer;
MOVE TempPointer NEXTSIBLING;
--SET Pointer = NULL;
MOVE Pointer TO TempPointer;
IF Sib THEN
MOVE Pointer NEXTSIBLING;
ELSE
SET KeepGoing = false;
END IF;
END WHILE;
END;
|
Output Message:
<Claim clmfileNumber="" clm="....." clmlossDate="2006-09-11" clm="....." clmlossTime="12:00:00" clm="....." clmServiceProviderRole="........................................." clm="....." clmlossType="" clm="....." clmcatCode="" clm="....." clmexcludeCode="" clm="....." clmamountPaid="" clm="....." clmAttorneyRole="..........." clm="....." clmlossLocation="......................................................................." clm="....." clmInvolvedPartyRole="................." clm="....." clmExposures="..........." clm="....." clmAdjusterRole="................." clm="....." clmstolenProperty="" clm="....." clmlossDescription="" clm="....." clmlaborRates="" clm="....." clmPolicyCoverages="..........." clm="....." clmSalvageRole="..........." clm="....." clmFileHandlers="..........." clm="....">
<fileNumber/>
<lossDate>2006-09-11</lossDate>
<lossTime>12:00:00</lossTime>
<ServiceProviderRole>
Those ... in the "" are actually carriage returns, slight annoyance.
Let me know if you need more info.
Thanks for the help! |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Mon Oct 02, 2006 12:23 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Why are you using Create.. Next Sibling instead of Set?
What domain are you working in?
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Tue Oct 03, 2006 4:36 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
xmlns
I'm using create...next because set won't keep the right order (or so i thought). I had pretty much copied the input root with a lil bit of modification to the output root. If I use SET then it puts it at the end(?) |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 03, 2006 4:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
It's the preferred choice to use XMLNSC with v6.
If you're inserting into the middle of a tree, yeah.. you probably do need to use create field. You should try looking at the IDENTITY clause of the Create statement.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Tue Oct 03, 2006 4:51 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
thanks, i'll give it a try.
I did try to use the XMLNSC.
That messed it up even more. (It made the new fields attributes of an ancestor 3 or 4 levels up). |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 03, 2006 4:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
The basic problem is that you're either not creating these fields under a parser - and so it's making a wild guess about what it should be - or that you're not giving these fields a specific field type (attribute, element, etc.) and so it's taking a default value that you don't want.
Start with the IDENTITY clause. If that doesn't fix it, then go back and re-read the reference on the Create statement, particularly the DOMAIN clause and anything else that seems to relate to parsers and node types.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Tue Oct 03, 2006 5:21 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
It appears that IDENTITY would correct the problem, except that with it, there isn't anyway to use a variable for the name of the field created, nor can you use the || operand.
I'll continue to try the other suggestions.
Thanks. |
|
| Back to top |
|
|
| special_agent_Queue |
| Posted: Tue Oct 03, 2006 5:27 am Post subject: |
|
|
Centurion
Joined: 27 Jul 2006
Posts: 102
|
| Thanks! Adding the DOMAIN clause worked. |
|
| Back to top |
|
|
|
|
