[Sergey Sevastyanov]

Blood|201

I didn’t test it though

[Sergey Sevastyanov]

Something to think about… We don’t use Java so we don’t have anyone to code it but if we get desperate we might have to learn 🙂

Thanks again!

[Sergey Sevastyanov]

Thank you, Jerry

So you connect to MS SQL via JDBC driver?

[Sergey Sevastyanov]

Same is here. We are very slow to move to a newer OS. As far as I know no plans for our hospital to upgrade to Win 10 yet.

[Sergey Sevastyanov]

Hi Brandon,

Do you run Cloverleaf on Windows by any chance? If so are you able to use Tclodbc on x64? We’ve been using tclodbc for a few years but now we are upgrading to Cloverleaf 6.2 and it runs in x64 bit process, so tclodbc doesn’t load anymore.

Thanks,

Sergey

[Sergey Sevastyanov]

Hi John,

We just switched over to Epic from Paragon this past weekend and today is our first weekday with Epic.

We used a mixed approach and for some downstream systems we chose the vendors to adopt Epic format while for some other systems we just translated Epic messages to Paragon format to make it transparent for the receiving system.

I tend to agree with Jim that it’s better to have the vendor to take new Epic format messages. Not only this will make your code clearer but also it’s not always possible to translate Epic messages to Paragon format because these two systems are so different.

[Sergey Sevastyanov]

Tom,

We upgraded from 5.7 on Win 2003 to 6.1.1 on Win 2008(test)/Win 2012 (prod) a few months ago.

I agree with James, 6.0, 6.1.0 had some problems, better go 6.1.1.

We had to change our code to use SQLite instead of GDBM. New 6.1.1 is much more stable than 5.7 (we skipped 5.8, so I can’t compare with with it)

[Sergey Sevastyanov]

Hi Shu,

I did something like that. It is possible to do in Tcl with some assumptions:

1. If you know for sure that OBX-5 is not a repeating filed and does not have any subfields; In this case you can assume that any special character within OBX-5 is just a character that should be escaped.

In this case you should start with escaping “” – otherwise you will end with escaping escaped characters.

2. If you know for sure that OBX-5 is the very last field in the segment; then you can treat all OBX fields starting with OBX-5 to the end of the segment as one filed that has embedded “|”. (If this is not the case then there is no way to know which “|” is part of OBX-5 and which is a field separator).

For example, if your OBX segment looks something like:

Code:

OBX|1|TX|||This is OBX-5 field with , ~, & and | embedded as part of the field. This is another | within the same OBX-5|

then the whole string “This is OBX-5 field with , ~, & and | embedded as part of the field. This is another | within the same OBX-5” should be treated as one field.

So, if both assumptions above are true you can do it like this (the code below may be not the best code but it worked in my tests; still you should test it):

Code:

# the next command is for testing purposes only
set obx {OBX|1|TX|||This is OBX-5 field with , ~, & and | embedded as part of the field. This is another | within the same OBX-5|}

set sep “|”
set fields [split $obx $sep]
set obx5 [string trimright [join [lrange $fields 5 end] $sep] $sep]
#  start with escaping “” – otherwise you will end with escaping escaped characters
regsub -all  — {(\)} $obx5 {\E\} obx5
# other escapes can go in any order
regsub -all  — {(&)} $obx5 {\T\} obx5
regsub -all  — {(~)} $obx5 {\R\} obx5
regsub -all  — {(|)} $obx5 {\F\} obx5
regsub -all  — {(^)} $obx5 {\S\} obx5]

set obx [join [lreplace $fields 5 end $obx5] $sep]

# debug only:
echo $obx

The code above produces the following output:

Code:

OBX|1|TX|||This is OBX-5 field with E, R, T and F embedded as part of the field. This is another F within the same OBX-5

Hope it helps,

Sergey

[Sergey Sevastyanov]

Mike,

No, to be honest, I didn’t have time to try as there are some more urgent issues.

I figured that I will try when (and if) I have more time to play. For now I settled on saving data in Tcl using TclODBC.

If you figure it out I appreciate if you could share.

Sergey

[Sergey Sevastyanov]

Thank you, Jim

[Sergey Sevastyanov]

Jim,

We are switching to EPIC from Paragon next spring and with that away go a lot of our in-house applications that uses direct access to Paragon database in real time.

I haven’t heard about Epic Data Handbook and I would be interested to see what APIs are available.

How do you get a cope of the handbook?

Thanks,

Sergey

[Sergey Sevastyanov]

Robert,

This looks like malformed ACK. It has messages ORM instead of ACK.

I don’t see msgType. Is the uppercase “REPLY” in the beginning a value of msgType that you didn’t paste?

Is your sending thread waiting for replies?

Depending on your settings (Waiting for reply checkbox) this message either treated as a reply or as inbound message.

If it is treated as ACK I wonder that Unsupported TrxID is causes by wrong message type. I am not sure how CL processes ACKs (if it cares about the message type in MSH). I looked at old recover.tcl and it seems it doesn’t care about MSH segment, only MSA. If it is still the case then ACK or ORM shouldn’t make any difference.

If it is treated as an inbound message then you may not have a route defined for ORM^O01.

I would ask your provider to change ACK type to ACK and see if this helps.

[Sergey Sevastyanov]

Also adding -Dhookloop=false settings makes it impossible to see if a message is selected (toggled) in SMAT – with that setting the background of selected message doesn’t change.

[Sergey Sevastyanov]

Jerry, check this thread

https://usspvlclovertch2.infor.com/viewtopic.php?t=7212&highlight=purge

There is 6.1.0.2 release that fixes issue with purging tables, but as far as I know it’s not publicly available and you have to open a case with Infor ask for that release.

[Sergey Sevastyanov]

David,

That worked! And very fast!

Thanks a lot!

Sergey

[Author]

Replies