Diagnosing application problems can be a tricky issue. Taken as a group, the questions below make up roughly 98% of ALL support requests we get for the UltraPort MySQL Schema Engine or the CORE HL7 MySQL Schema Engine. This means that if you are having an issue with the SQL Schema Engine the odds are better than 9 out of 10 that you can find your answer by reading through the sections below.
#1. The Schema Engine works when Running Locally but nothing happens when Running as a Service. Our #1 support call! Your answer is almost certainly in #2 or #3 (or both) below.
#2. Using Network Drives, Mapped Drives or Virtual Drives. It works fine when running locally BUT when running as a service it will start BUT doesn't appear to be processing messages. The #2 support call we get here is from customers who want to use network shares / mapped drives / virtual drives to host the data folder in their profiles. This will cause issues for you because MS Windows Services are unable to access network resources. The thing to remember is that when you are creating your profiles or running your profiles locally you are logged into your network. Thus you can see all of the 'Network Places' which you have access to and any mapped drives which are part of YOUR login script. The SQL Schema Engine's MS Windows Services on the other hand are (by default) running under the "Local System" account which exists ONLY on your computer, doesn't have any access to network shares or to ANYTHING which resides in a login script (like mapped drives). This is done on purpose because your service needs to be able to start when the computer BOOTS UP and before anyone logs in (thus you're protected from power outages in the middle of the night). If you absolutely must use network shares then you will have to go into the MS Windows Services, right click on the CORE SQL Schema Engine services and select select "Properties". In the properties tab you can configure any windows service to run as a particular domain user. This is NOT our requirement here at TransWorld Scribes, it's a requirement of Microsoft. Getting this to work is notoriously tricky because so much depends on your own network security policies regarding user access/logons. It's because of this that this is one of the things that we probably can't do much to help you with. If you need to contact us for support and your profiles are using network drives for the data folder the first thing we will instruct you to do is to use a local drive and try again. If that works, then we have identified that the issue is with user access rights and the MS Windows Service and there's really not much else we can do.
#3. It seems to be "stuck" trying to process or train a HL7 message. This problem can usually be traced to the MySQL User ID you have chosen in your MySQL Connector in your Schema Profile. Troubleshoot this by changing the MySQL logon to the root account (just temporarily) and try running again. If it works this time, then revisit the MySQL logon that you were using and make sure that it has FULL rights to your MySQL database.
#4. HL7 message data files are piling up in the data folder and are not being imported. If you have determined that the problem is NOT #2 or #3 above then you should inspect the HL7 message file itself. A quick way to do it is like so:
•Stop the MySQL Engine Services (if running).
•In the data folder, sort by last modified ASCENDING so you can see the OLDEST file. This will be the one that the schema engine is trying to process.
•CUT that file from the data folder and paste it into a safe place for a moment.
•Restart the MySQL Engine Services (or Run Locally).
•IF your processes start processing messages again, then it's time to have a look at the file you cut out because it is likely corrupt in some way.
For #4, why would the Schema Engine not skip the message file and move on to the next? A reasonable question. IF we encounter a data file that is completely corrupt, example might be if a grocery list file somehow made it into the data folder with the proper file extension, the Schema Engine will move that file into the CME_Errors sub-folder of the data folder. If, however, we actually are able to detect what we think is a HL7 message in the file BUT it has some other form of internal corruption, the Schema Engine may "stick" on that file, trying to process it, failing, and then retrying every 60 seconds while it waits for YOU to rescue it.
THIS IS BY DESIGN, it is NOT a bug. HL7 messages contain patient medical information and we take that seriously. Since we don't know exactly what types of messages you might be processing, we just assume that the "stuck" message is a notification that the patient has a deadly peanut allergy, and the NEXT message is a lunch order to food services ordering a peanut butter sandwich for the patient's lunch. In that situation it is vital that you are made aware of the contents of this "stuck" message.
A great tool to help you is our FREE CORE HL7 Viewer software.
CORE HL7 Viewer
Starting with version 3.0 you can use our CORE HL7 Viewer to query and retrieve HL7 messages from your CORE HL7 MySQL Schema Engine database schemas.
View the Online Help for the CORE HL7 Viewer.
Here is also a Direct Download Link for the latest version.
