Problems with newline stripping when saving a file.

Problems with newline stripping when saving a file.

2
NewbieNewbie
2

    Mar 10, 2005#1

    I'm having a particular problem when saving files using UE 11.00a

    I'm trying to open up a file that has a bunch of records, each record is newline delimited. Let's say I have a string (shown in hex)
    75 6D 6E 20 0D 0A 4D 53 48 7C 5E 7E 5C 26 7C 41 ; umn ..MSH|^~\&|A

    When I save the file, the 0D 0A becomes 0D. This is a problem. Is there any way to prevent this? I've setup UE to "save file as input format", which doesn't seem to change anything.

    Basically what I would really like is if there was some way to force UE to treat the file as binary and not make any changes to newlines.

    Any thgoughts?

    Thanks,
    Jeff

    1

      Mar 10, 2005#2

      Based on the data, you are trying to view HL7 data in UE. I have been doing so for 9 years now (I'm in the healthcare field) and UE works just fine. The issue is your end of message delimiter. Usually in HL7 it's hex 1C0D, not 0D0A. If you have UE set to "Save file as input format", it reads the 0D character at the end of each segment and (for display purposes), changes it to 0D0A so that each segment shows up on a different line (very handy I think). However, when it goes to save the file, it changes all the 0D0A combinations back to 0D. But since your messages ALSO end in 0D0A, it changes them as well. My guess is that the application that writes your HL7 messages to a log file changes the 1C0D to a 0D0A so that someone could somewhat view the data in notepad, even though it looks horrendous in notepad. Can you change your application so that is does NOT change the 1C0D characters to 0D0A? If not, you can run a macro on your HL7 files when you first open them that will change the 0D0A to 1C0D, close and reopen the file and viola, UE will not mess with the end of message delimiter any more.

      Hope this helps,
      George

      2
      NewbieNewbie
      2

        Mar 24, 2005#3

        Yeah, it's HL7. I've been using UE for a long time with HL7 as well. I won't get into the specifics as to why the data is formated as it is, but it is written this way by design, lets just say it's HL7 + non hl7 data purposefully stuffed in a single "record". I never had any problems with older versions of UE changing the characters, it seems like an 11.0 feature (bug) (this didn't happen on an older version of UE 10.2). I gues my issue right now is UE should not mess with the data in a file if I don't want it to.

        Jeff

        6,686585
        Grand MasterGrand Master
        6,686585

          Mar 24, 2005#4

          I never saw a HL7 file, but I had a similar problem editing Opera mail files with mixed 0D 0A / only 0A / only 0D usage in one file. I turned off any auto-detecting and auto-conversation feature of UE in the general configuration dialog and then I could edit it and UE does not change the type of line break.
          Best regards from an UC/UE/UES for Windows user from Austria

          1

            Jan 14, 2008#5

            I concur that this is an issue that started after v10. I have deliberately kept one pc with the older version to make sure I could edit HL7 files.

            In HL7 each segment of a message ends with 0d. Each message ends with 0a. Therefore to properly format an HL7 message the last two bytes of the message have to be 0d0a.