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 MS SQL Schema Engine or the CORE HL7 MS SQL 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 the SQL "Trusted Connection". When creating your Schema Profiles you have the option of selecting the "Security Protocol" which the Schema Engine should use when connecting to SQL Server. IF you select "Windows Logon (Trusted)" this means that when profiles run they use the current log-on of WHOEVER is logged into windows at that time. This can have several unfavorable results. Number ONE is that IF you have a professional license AND you wish to run the MS Windows Services (see Running as a Service) you must remember that all MS Windows Services run in a separate memory space and under different logon credentials. You must configure the MS Windows Services to run under the context of a User ID which has a trusted connection to the database. If running locally, you must make sure that you are logged into MS Windows with a User ID which has a "Trusted" connection to the SQL Server AND adequate user rights to the database and tables. BEST OPTION: If at all possible, we highly recommend that you choose "SQL Server User ID" in the "Security Protocol" section of your schema profile. For more information on SQL Server Security and Authentication refer to your DBA or MS SQL Server documentation.
#3. 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 HermeTech, 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/logins. 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 HermeTech for support and your processor 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.
