[Jason Puskar]

All,

Thanks again for the help and coding suggestions.  As it worked out for us, we don’t need the blank space so I used the method to only copy over the fields when the length is > then 0.

Jay

[Jason Puskar]

Jim,

I like the string map idea and tried it myself.  I must not have the right syntax.  How would you code it?

[Jason Puskar]

Hello,

    Thank you both for the help!!!  I see now how I could have used the in the xlate would have worked now.  I tried a few different versions of using that prior to the update you gave, but not successfully.  I am going to keep this reference for the next one I may need to do.

    I ended up taking the advice of doing it in a stored procedure.  First I did a bulkcopy to get the entire message.  I then pulled the fields that I needed separately and stored them in a Z segment (ZFM), passing this all over to a procedure.  I then created the stored procedure to pull the values from the Z segment, from the full message, and stored them all in the database.  

Thanks,

Jay

[Jason Puskar]

Jim,

   I did think of the two transactions, but what would be the field I could use?  If I can only send the full message in a bulk copy, I”m still not sure how to pull out specific fields.  Is there a way to pull fields out of the bulk copy to send?

Jay

[Jason Puskar]

Peter,

    Agreed!  I too would have liked to use that format.  Maybe when the project pressure is off, I will have better success with the name = value syntax.  It seems to be a better way to go, especially when it comes to updates in the future…………

Thanks again,

Jay 😀  😉

[Jason Puskar]

Hello all,

   Thank you for the responses.  I have listened and attempted all the suggestions.

    I have tried removing the quotes, and I get the below syntax error:

[java:wrte:ERR /0:mt_orm_transport_update_0:07/05/2018 09:27:02] Call to “doMsg” returned error string “BADDATA caught exception trying to processMessageFromCloverleaf: Failed to write message to database: Incorrect syntax near ‘<'.". Returning bad send to engine.

    I also did you use the temp TCL code to see what is leaving the engine.  That was a nice debugging tool thanks.  The VRL is returning the correct values with the commas in the right spot.  

    I was trying to use the SP @name=value format yes.  I thought it may be easier for others to follow behind me.  However; after having no luck with this, I think that I will just use the positional parameter syntax.  I have had success with that format after populating the database just fine.  With the time frame that I have, I will get it to work for now, then maybe go back to the SP @name=value format at another time.

Thanks again!

Jay

[Jason Puskar]

Jim,

   Thanks so much for your help.  I was able to get this to work based on what you said.  

   I valued my own variable of $%s99 to 1.  I am still using the usual %s1 to loop through the OBX segments.  Once I find a value I want to copy, I just use the $%s99 variable on outbound side.  Next I increment my own custom variable by one for the next match.

     Below is how the initializing, copy and incrementing looks in the xlate:

Copy

=1   –>   $%s99

Match found, now copy to outbound:

1(0).1(0).1(0).OBX(%s1).#5(0).[0]   –>   1(0).1(0).1(0).OBX(%s99).#5(0).[0]

Math:Add

$%s99   –>   $%s99

=1

[Jason Puskar]

Thanks for the maint thought.  We do have things running, perhaps there are times when this conflicts.  The uPOC was running 2xs a day, but we added a third at 1am.  Looks like that’s when the file is having issues.  Will move to 2am and see what happens.  

THANKS!

[Jason Puskar]

Hi,

   Quick question, why not do this in an xlate?  Seems straight forward enough to do it there no?

Jay

[Jason Puskar]

Hi,

   I am playing around and seems to be what we are looking for!

Jay

[Jason Puskar]

Jeff,

   Thanks!  I took your suggestions and applied to my script.  I was able to create the files from embedded PDF’s from the OBX|5 segment(s).

Jay

[Jason Puskar]

Thank you!  I will work with the vendor to send them multiple OBX’s

[Jason Puskar]

Jim,

    Right now the Protocol Driver Control field contains the name of the file.  Part of the name is the Visit number for the patient.  For ease of viewing/searching, the idea was to pull out the Visit number and place in the User Data field.  Since I cannot do this, then we can continue to search Driver field.

Jay

[Jason Puskar]

Jim,

    Thank you for the response.  I wanted to use this on the inbound thread of an sFTP to store the patient ID.  There is no outbound SMAT as these files are rather large (.PDF).

Jay

[Jason Puskar]

Thanks!!  Works pefectly after some tweeking

[Author]

Replies