Thanks for responding!

Yes, I agree that it sounds like I'm just not looking in the correct place, but unfortunately, I'm already searching at the highest part of the tree just as you indicated (DC=company, DC=local). The based DN is not being appended to the full DN I gave as the username.

Because the search user authenticates, I don't believe it's a connection issue. I've searched using the full DN (CN, OU, DC), using uid=, using sAMAccountName=, and using just the actual username. I'm relatively new to Linux, so I was hoping it was some simple methodology that had to be used when connecting to a Windows AD server.

I did try an additional "To" that failed. However I just did it again and it worked. I assumed it failed because Concord Fax did not support it, but I must have had something else incorrect that has since then been fixed.  Thank you for the sanity-check!

Hello Joe

Thank you for your response. Please forgive my lack of experience, but how do I invoke this method from within the DTL? I tried placing it in code tags and then calling it like this, but that appears to not be with way.

<assign property='target.{MSH:7}' action='set' value='..GetLocalTimeWithUTCOffset(source.{MSH:7})' />

Thank you, Joe, this worked perfectly!

Yes, I just found that at the bottom of the $PIECE document. Thank you, Robert!

Thank you, Robert, that is exactly what I was looking for!

Thank you, Eduard! This is really interesting. It looks quite a bit more verbose.

does the "IMPRESSION TO FAX" rule work if its the only rule?

That's a good reminder of how to simplify the test. It did not work when it's the only rule.

it would be good to have a look at the business rule log

I did look at it, or rather thought I was. I looked again this morning and there were errors. I must have accidentally opened the event log on the wrong process yesterday. Thank you for the sanity-check!

As expected, tSQL looks like:

UPDATE table_name (updated,order_system_name,site_code,patient_id,patient_alternate_id,patient_last_name,patient_first_name,patient_middle_name,patient_dob,patient_sex,patient_address_1,patient_address_2,patient_city,patient_state,patient_zip,patient_account_number,patient_ssn,visit_class,visit_unit,visit_facility,attending_doctor_id,attending_doctor_last_name,attending_doctor_first_name,referring_doctor_id,referring_doctor_last_name,referring_doctor_first_name,consulting_doctor_id,consulting_doctor_last_name,consulting_doctor_first_name,admitting_doctor_id,admitting_doctor_last_name,admitting_doctor_first_name,visit_number,admit_datetime,discharge_datetime,accession_number,status_code,order_completed_datetime,placer_order_number,filler_order_number,procedure_code,procedure_description,ordering_doctor_id,ordering_doctor_last_name,ordering_doctor_first_name,procedure_modality,order_priority,reason_for_exam) VALUES (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?) WHERE accession_number='123456789'

SQL requires comma's between column names and the question mark placeholders, and patient_id is not the first column to be written. The sqlColumns and sqlValues strings are seeded with "updated" and "?" before new columns are added.

I have not, but that's a good suggestion. I may also rework the script to not use a parameterized (is that a word) update query and see if that works.

If I use a standard value assignment (SET mrn = '123456', lastName = 'Smith', etc.), it works just fine pulling the values from the HL7 message and writing them to the appropriate columns. I'm going through the code and adding corresponding lines for each variable I wish to store:

Set valueAssignment = valueAssignment_", site_code = '"_siteCode_"'"
...
Set tSQL = "UPDATE table_name"_valueAssignment_" WHERE accession_number='"_accessionNumber_"'"

I'm hoping that there may not be an issue with the parameter binding at all and it's just some odd value in one of the fields, although everything looks fine. Once I get through added that line for all of the variables in a day or two, I'll know for sure. So far, it's nothing in MSH, PID, or PV1.

I'll reply back once I know.

Standard value assignment does work for updating the record. I also looked at every open parenthesis in the code just in case something looked off, but it all seems to be fine.

It appears the issue may be the dynamic statement parameter binding. 

Well maybe I am hitting a limit then, because there are 48 variables.

The error is reported at execution. I see it in the interface's log. I get no errors when compiling the ObjectScript.

Odd(ish) the limitation is on the UPDATE but not on the INSERT. I will follow up with the WRC and see if I can get a definitive answer.

I am using the parameters to avoid code insertion (not that I'm terribly worried about it, but it's just good practice). If I cannot do that, then I'll have to do some kind of variable cleaning on the string, or perhaps define each as a %STRING literal or something. Whatever the best practice is for ObjectScript.

Hi Jeff

TOP...of course! Yeah that only returns one result when I run the query in the SQL window. However, I still do not get the FullMessage variable populated from the query when run in the DTL, so the "SELECT TOP 1 Full_Message INTO :FullMessage" bit is not working.