Hi everyone, please check out our new discussion forum located in our GitHub site: https://github.com/nextgenhealthcare/connect/discussions. Let us know your feedback as we try out this new part of GitHub! Don't worry, the content in these forums won't be going away and will at a minimum be preserved for historical reference.
I'm moving messages (files) after they're parsed in a directory and named them sa ${ORIGINALNAME} and everything is working fine but at my Destination, I have an insert statement that inserts ${ORIGINALNAME} into a field and instead of saving the Original Name, the format is saves is <systime>.dat. is this a bug or I did something worng?
Also, the reason for this one is I'm trying to save the original HL7 message into a SQL Server table for future use or maybe for reparsing of the file. I'm using SQL Server 2005 for this one.
INSERT IGNORE INTO HL7FileArrival
(FileName, TransData, FileETA)
SELECT 'D:\Message_IN\' + ${ORIGINALNAME}, BulkColumn from Openrowset( Bulk 'D:\Message_IN\' + ${ORIGINALNAME}, Single_Blob) as FileM, getdate()
I believe this may be a bug. I created a simple file to file channel using ${ORIGINALNAME} in both the move-to-filename as well as the file name of the destination file.
The move-to-filename is retaining the correct original name, however the destination filename is a 13 digit .DAT file.
Chris, can you see if there is any misconfiguration in the channel. I will paste it below.
Unfortunately, it is not a bug. Mirth doesn't carry state information about the filename to the destination, so there is no "original name" variable. It uses a randomly generated GUID to do the processing. We'll look into removing the originalName var from the destination tab in the next release.
We process personal data about users of our site, through the use of cookies and other technologies, to deliver our services, personalize advertising, and to analyze site activity. We may share certain information about our users with our advertising and analytics partners. For additional details, refer to our Privacy Policy.
By clicking "I AGREE" below, you agree to our Privacy Policy and our personal data processing and cookie practices as described therein. You also acknowledge that this forum may be hosted outside your country and you consent to the collection, storage, and processing of your data in the country where this forum is hosted.
Comment