Notifications
Clear all
Topic starter
We're working on debugging a pretty big, as of yet unsolved, crash issue on a recently upgraded Centricity 12.2.2, and none of our logs are telling us much. But! There are some logs in the Users/username/AppData/Local/Centricity/Logs folder that I don't know how to access. I thought I'd ask if anyone else does!
Debug: Open About Centricity, in the box in the lower left-hand corner enter "0xFFFFFFF". This will run in debug mode until you return to the About window, enter 0x0, log off, and log back on.
Edi:
ExceptionsAndErrors: You turn this on in Options Tab -> Preferences -> System -> Application. Check the "Error Logging" checkbox. Any error will log to this file. I think it's just the same thing that prepends to the ERRORLOG_x file in Crash Logs, though. Apparently PHI can leak into this, so do be careful how you use it and for how long!
Mik:
Performance:
SQL Trace: Ctrl + Alt + S runs the SQL Trace. You will see [*SQL Trace*] in the bar. This logs all the SQL query that are called while the trace is running.
Trace: Ctrl + Alt + D runs the Trace, which is actually a database trace. You will see [*DB Trace*] in the bar. I'm not sure exactly how this differs from the SQL trace, as both logs look similar.
TraceMel: Ctrl + Alt + M runs the MEL Trace. You will see [*MEL Trace*] in the bar. This tracks all the MEL code that runs when you load, use, and run forms. This is occasionally great for debugging MEL forms when you have no idea what is happening.
Does anyone else know how to access the other traces and what they do? I feel like ExceptionsAndErrors could be a very powerful tool to help us discover what exactly is going on with our system.
Tangential question: I have a loooong document I've cobbled together on MEL and how to use it on an advanced level. Is there a way to turn a thread like this into a knowledge base, or a place we could create something more like that? Instead of having to pore over threads and piece together solutions about how to write effective MEL code, it would be great to have a one stop shop, where we could all learn from each other's struggles.
EDIT: Added info to ExceptionsAndErrors section
Posted : October 11, 2017 3:44 am
Re: ALL TRACE FILES - Remember to delete the trace file when you have finished reviewing it. Trace files append to the end of the existing file each time a trace is run and can eat up disk space rapidly. If the file grows too large, it can be painful to work with and require a third party tool to split into smaller chunks (Oracle version only). Note - CPS limits the file size for you, but having hundreds of smaller files is just as bad as having one large one. 😉
1) At minimum, EVERY form should be MEL traced prior to active use in production. I recommend MEL tracing be performed periodically on all forms in use to ensure that updates to the EMR have not adversely impacted functionality. Many developers mistakenly believe that because a form appears to work visually, it is error free. A MEL trace will reveal not only hidden errors, but recursive executions, inefficient 'trigger' control, and unseen issues like variable collisions. It is, in my opinion, THE debug tool for form builders.
2) DEBUG data symbol - this is a MEL command that you insert into your MEL code. It is useful for tracing a section of code that is misbehaving. To turn on, inside the bothersome section of code, use
debug("driveletter:\\Path\\and\\filename\\to\\write\\to.txt")
Note that the backslashes are doubled. If no path is specified, it will write the file to the current active directory (typically the EMR client folder) with the name 'debug.txt'
To turn off, use:
debug()
Remember to remove these two commands from your code when finished.
3) The SQL and Database traces are mostly the same. The difference is that the database trace also includes volatile memory tables (temp tables created in memory).
With regard to an information repository or 'wiki', it would/should require an active review system to both validate and re-certify each entry after each EMR version/patch. Each post would need to be 'certified for version X' to be of any real use and not add to confusion/misunderstanding. It is a rather large undertaking that would require the entire community to maintain, otherwise it will devolve into the same source of poor and outdated information like the old medicalogic knowledgebase did years ago. Should it be attempted again, to be of any real use, strict discipline would need to be applied. One topic per post to make finding easier and very limited discussion permitted (no Q-n-A; perhaps only comments on if it is (still) valid or not), otherwise the nugget gets buried in the gravel...
First of all, though, we would need forum software that actually handled the posting of code snippets properly and easily (i.e. maintained all characters and formatting). This forum, unfortunately, is not ideal for that purpose.
Posted : October 13, 2017 4:56 am
Topic starter
That's some great info, Lee. Regarding the debug piece, if I insert that debug code into my code, only the section after that piece will be debugged? And is that the same process as actually turning on the debugger in the About section?
Posted : October 13, 2017 5:07 am
It will turn on when it finds the first instance and turn off when it finds the second (as long as it does not specify the path/filename).
It is the same debug info, but it is not well known, hence why I included it. It is very useful for tracing only a section of the code, ie. you want to visualize the routines between two functions without having to pour over the entire trace each time. I use it periodically when I have functions misbehaving and it saves a lot of time. Of course, I still perform a final FULL trace before I ever call a form 'done'. 😉
Posted : October 13, 2017 5:24 am