Forum Replies Created
-
AuthorReplies
-
It’s not really feasible because when will you know that all the results have been received? How long do you wait before sending them?
We’ve had similar requests in the past but this is really something that needs to be solved in the application/presentation layer, not the interface. The closest we managed to come up with was one thread that would write results to a database and another that would poll on a set schedule, but then you end up with results being delayed which no one wants.
Do you have the mid# from the recovery DB?
If so it’s just:
hcidbdump -r -L -m $midGoesHere
Sorry to bump this, but we just saw this same error on the same OS/Cloverleaf revision.
Did you ever find out the source?
Funny that you posted this just as I tried that, and yeah it seems to work.
Thanks, Jim!
I’m working on this with support right now. Our site always seems to have these weird issues 😀
I had tried using a list on the outbound, but I don’t think I ever did the same on the inbound.
You’re the man Charlie. If you get a chance to come back to Winnipeg, I owe you a beer.
Hmm, okay this seems to be working now, although I used only \ instead of \\ before and after in the escape sequences.
Can you explain how this is any different than what I had before? Is it simply returning it in a list that makes it work? When I did that before anything with a space in it was returned wrapped in {} but this doesn’t do that…
Well the code I have works, but Cloverleaf somehow modifies the correct, returned string from TCL.
I’ll try yours and see if it improves at all, Charlie.
I’ve tried all these suggestions with no luck.
It works in *most* cases, but not all. It seems as though there is another layer of evaluation that happens when TCL passes the string back to the engine and it can’t handle the HL7 escape sequences.
Interestingly enough, the TCL proc contains the correct value, it’s just when the translation is run the message does not contain what TCL is returning.
I *can* get the message to show the correct escape sequences if I return the values by wrapping them in a list command (i.e. set XlateOutVals
-
) but this introduces braces in values that have a space in them, which then shows up in the message.
There has to be another method that will work here. My code at the moment is:
Code:proc xltp_ReplaceContCharInline {} {
upvar xlateId xlateId
xlateInList xlateInList
xlateInTypes xlateInTypes
xlateInVals xlateInVals
xlateOutList xlateOutList
xlateOutTypes xlateOutTypes
xlateOutVals xlateOutValsset inRecords $xlateInVals
puts “VAL IN $inRecords”
# Assign all the control characters and escape sequences to variables
# This step was suggest by Lawson to help with some unusual results from the proc.set HL7Esc “\”
append newAmp $HL7Esc T $HL7Esc
append newSlash $HL7Esc E $HL7Esc
append newPipe $HL7Esc F $HL7Esc
append newCarrot $HL7Esc S $HL7Esc
append newTilde $HL7Esc R $HL7Esc# String map out all the control characters
set inRecords [string map [list & $newAmp \ $newSlash | $newPipe ^ $newCarrot ~ $newTilde] $inRecords]
puts “VAL OUT $inRecords”
set xlateOutVals $inRecords
}In the event that the value passed is APO-BU&IPRONE, it should return APO-BUTIPRONE but I get APO-BUTIPRONE. Oddly enough, if I send it APO-BUIPRONE it correctly sends back APO-BUEIPRONE.
This is incredibly frustrating.
And nevermind… I looked through the batch files that were installed on the client and sorted it out.
For anyone looking for a future reference:
There are five batch or executable files we can use to control the state of the courier and dispatcher:CSCSTOPDISP.BAT [code]There are five batch or executable files we can use to control the state of the courier and dispatcher:
CSCSTOPDISP.BAT
Hi Jim,
I took that into account, and it’s definitely not a length issue. I can have && as the only values in a field, and it still comes back to the engine as TT
Honestly there seems to be another layer of evaluation when TCL hands the string back the engine, and it freaks out whenever the back slashes are involved.
So why does Quovadx still train people to use Bulkcopy? We have new staff members here that were trained within the last two months, and Bulkcopy is still recommended as the best way to write translations… Try using string match instead of string equal. Match uses glob-style expressions and should only match ‘test’ exactly. I think you can still use the -nocase argument. That’s the way I’d do it. You could nest them to make it one line, but no big deal: Code:set subfield [lindex [split $field $fieldSep] 0]
Why not just uppercase the field and compare it that way? so:
Code:if {[string equal [string toupper $subField] “TEST”]} {
#Do whatever
} -
AuthorReplies