We have data that is stored in an attribute with multiple values and up to two sub-values per value. Using an I-type dictionary, I have found that I can only extract specific sub-values if any sub-value marks are converted to another character first.
For instance, the following will not work for attribute 2 (formula) in the dictionary to retrieve the first sub-value:
FIELDS( @RECORD<77>, @SM, 1, 1 )
Instead, we have resorted to using the following:
CONVERT( @SM, "`", @RECORD<77> ); FIELDS( @1, "`", 1, 1 )
Just curious if this is an expected behavior or if anyone has found a more elegant solution.
Thanks!
------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
We have data that is stored in an attribute with multiple values and up to two sub-values per value. Using an I-type dictionary, I have found that I can only extract specific sub-values if any sub-value marks are converted to another character first.
For instance, the following will not work for attribute 2 (formula) in the dictionary to retrieve the first sub-value:
FIELDS( @RECORD<77>, @SM, 1, 1 )
Instead, we have resorted to using the following:
CONVERT( @SM, "`", @RECORD<77> ); FIELDS( @1, "`", 1, 1 )
Just curious if this is an expected behavior or if anyone has found a more elegant solution.
Thanks!
------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
In UniData we use EXTRACT(@RECORD, 77, 1, 1)
------------------------------
David Green
Computer Programmer
Rocket Forum Shared Account
------------------------------
We have data that is stored in an attribute with multiple values and up to two sub-values per value. Using an I-type dictionary, I have found that I can only extract specific sub-values if any sub-value marks are converted to another character first.
For instance, the following will not work for attribute 2 (formula) in the dictionary to retrieve the first sub-value:
FIELDS( @RECORD<77>, @SM, 1, 1 )
Instead, we have resorted to using the following:
CONVERT( @SM, "`", @RECORD<77> ); FIELDS( @1, "`", 1, 1 )
Just curious if this is an expected behavior or if anyone has found a more elegant solution.
Thanks!
------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
Hi Jeff,
If you are looking to get the 1st subvalue in the first value of attribute 77, then the syntax @RECORD<77,1,1> should give you what you want. Unless I'm misunderstanding what you are after.
Thanks,
Neil
------------------------------
Neil Morris
Universe Advanced Technical Support
Rocket Software
------------------------------
Hi Jeff,
If you are looking to get the 1st subvalue in the first value of attribute 77, then the syntax @RECORD<77,1,1> should give you what you want. Unless I'm misunderstanding what you are after.
Thanks,
Neil
------------------------------
Neil Morris
Universe Advanced Technical Support
Rocket Software
------------------------------
Thanks, Neil, but the issue is getting each 1st sub-value from each value in a set of values. That's why the 'FIELDS' syntax is being used. If I were getting a specific sub-value, I would certainly use the syntax you suggested. In this particular case, the values represent names for customers where the sub-values are the primary and secondary ID's for each customer.
------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
Thanks, Neil, but the issue is getting each 1st sub-value from each value in a set of values. That's why the 'FIELDS' syntax is being used. If I were getting a specific sub-value, I would certainly use the syntax you suggested. In this particular case, the values represent names for customers where the sub-values are the primary and secondary ID's for each customer.
------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
Hi Jeff,
What you do in the original post is basically what you need to do. All of the MV functions (including FIELDS) work not just on value marks but on any of the system marks, so you basically can't use those marks in those functions.
------------------------------
Tyrel Marak
Technical Support Manager
Aptron Corporation
Florham Park NJ US
------------------------------
We have data that is stored in an attribute with multiple values and up to two sub-values per value. Using an I-type dictionary, I have found that I can only extract specific sub-values if any sub-value marks are converted to another character first.
For instance, the following will not work for attribute 2 (formula) in the dictionary to retrieve the first sub-value:
FIELDS( @RECORD<77>, @SM, 1, 1 )
Instead, we have resorted to using the following:
CONVERT( @SM, "`", @RECORD<77> ); FIELDS( @1, "`", 1, 1 )
Just curious if this is an expected behavior or if anyone has found a more elegant solution.
Thanks!
------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
The reason the conversion is necessary is because the FIELDS function operates using the standard delimiters which include the Subvalue mark. The way you are currently doing this is correct and how we have done on our system. That being said, I have also experimented and created a routine that would allow me this syntax.
SUBR('FieldSF', @RECORD<77>, @VM, @SM, 1, 1)
To me that makes it clearer and more maintainable, but unless you want to create your own routine, you would need to continue doing the conversion within the dictionary.
------------------------------
Joseph von Arx
President
Data Management Associates Inc DMA
Cincinnati OH US
------------------------------
We have data that is stored in an attribute with multiple values and up to two sub-values per value. Using an I-type dictionary, I have found that I can only extract specific sub-values if any sub-value marks are converted to another character first.
For instance, the following will not work for attribute 2 (formula) in the dictionary to retrieve the first sub-value:
FIELDS( @RECORD<77>, @SM, 1, 1 )
Instead, we have resorted to using the following:
CONVERT( @SM, "`", @RECORD<77> ); FIELDS( @1, "`", 1, 1 )
Just curious if this is an expected behavior or if anyone has found a more elegant solution.
Thanks!
------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
The reason that you need the CONVERT is because the FIELDS function operates on all system delimiters including the SubValue mark. How you use the CONVERT is exactly how I've handled this situation on our system. That being said, I have also experimented and created my own function that would allow me to use the following syntax instead, which I find clearer and more maintainable.
SUBR('FieldSF', @RECORD<77>, @VM, @SM, 1, 1)
------------------------------
Joseph von Arx
President
Data Management Associates Inc DMA
Cincinnati OH US
------------------------------
The reason the conversion is necessary is because the FIELDS function operates using the standard delimiters which include the Subvalue mark. The way you are currently doing this is correct and how we have done on our system. That being said, I have also experimented and created a routine that would allow me this syntax.
SUBR('FieldSF', @RECORD<77>, @VM, @SM, 1, 1)
To me that makes it clearer and more maintainable, but unless you want to create your own routine, you would need to continue doing the conversion within the dictionary.
------------------------------
Joseph von Arx
President
Data Management Associates Inc DMA
Cincinnati OH US
------------------------------
Another good response, Joseph! Using the subroutine allows it to be generalized where the second argument can be any attribute and the first "1" can be which sub-value you need, e.g., 1, 2, 3, etc. Since the dictionary is built in a specific file, the subroutine can be agnostic as to which file, the dictionary processor supplies it.
An aside, I found out recently that using I-type dictionaries in Retrieve supplies the "@FILENAME" parameter but using "ITYPE" in UniVerse Basic requires that the user set that variable before executing the "ITYPE" function. If it's not supplied, the results are different between Retrieve and Basic.
------------------------------
Jeff Teter
Woodforest National Bank
The Woodlands, TX
------------------------------
