Hello. I have this line of code that is giving me weird results in the MEL trace file, and thus, a problem in the form. I have a line of code that attaches four 0000s to the end of the patient's PID #. Since the patient can have more than one Participant ID #, I have the form looking at the last value and adding 1 to get the next sequential #.
TMPVAL = replacestr(str(val(OBSPREV("PARTICPNT ID")) + 1),".00","")
Below, is the portion of the trace file where this line is executed. As you can see, the value in the last Participant ID # is 20080101278260002 (PID portion changed to protect the innocent). However, when it goes to add the 1, it converts the number to 20080101278260000.00. It's like the 2 is being converted to a 0 for some reason. This is the only patient where I'm having this problem. This code has been working for all other patients. Any clues why this is happening?
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> call OBSPREV("PARTICPNT ID")
07/01/2019 Process Id #3968 ML Thread [MelTrace] results> "20080101278260002"
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> call VAL("20080101278260002")
07/01/2019 Process Id #3968 ML Thread [MelTrace] results> 20080101278260000.00
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> 20080101278260000.00 + 1
07/01/2019 Process Id #3968 ML Thread [MelTrace] results> 20080101278260000.00
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> call STR(20080101278260000.00)
07/01/2019 Process Id #3968 ML Thread [MelTrace] results> "20080101278260000.00"
07/01/2019 Process Id #3968 ML Thread [MelTrace] execute> call REPLACESTR("20080101278260000.00", ".00", "")
As always, your help is greatly appreciated.
Robin Tardif
I found another instance where a similar thing is happening to several different patients. I have a display field that has the following code: LAST_SIGNED_OBS_VALUE("PARTICPNT ID")
It reports the correct value of 5446930001. When I change the code to val(LAST_SIGNED_OBS_VALUE("PARTICPNT ID"))
the result is a completely different value of 1151962705.
How is that possible? Since the first value is a number, the value shouldn't change just by putting the val() around it. Is this a memory address? A faulty computer processor? Me going crazy?
Has anyone else seen this? This is occurring in CPS 12.3.2, by the way.
Thanks again.
Robin
It appears that val returns a numeric value as a float data type that has to round the value because it is so large. I did a little testing. 20080101278260001 and 20080101278260002 both round down to 20080101278260000, whereas 20080101278260003 rounds up to 20080101278260004.
If you want to use this logic, you're going to have to use a smaller number to make it work.
Thank you for your help. Because I can't change the length of the existing PID, I decided to use a different method to create a unique application number. That way I don't have to deal with these long PIDs.
Thank you for explaining what was going on. I thought I was going crazy.
Robin
So this is the PID + 4 digits? If the only thing that should change is the last 4 digits, then we can separate the PID from the last 4 digits, modify the smaller number, and then recombine them. Does that work for your scenario? This Patient ID in your example seems very long, but as long as the last 4 digits is always the ones that change, this can work.
Here is an example of what I mean.
tempPartID = remove(PartID, len-3,4)
ZeroStr = ""
//check for how many 0's need to be added before re-attaching
cond
case TempNum <10
ZeroStr ="000"
case TempNum <100
ZeroStr ="00"
case TempNum <1000
ZeroStr ="0"
else
ZeroStr =""
endcond
Let me know if you have any questions
Thank you for your help. I ended up using a different method to create a unique application number. I'm using a date/time stamp with other info. I should have done that in the first place, but I was trying to give the person creating the reports an easy way to sort and group the data.
Again, thank you. I do appreciate the help.
Robin