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 3:56 am
