In the course of working with the DR, you’re going to wind up setting up scheduled jobs through SQL Agent, and – inevitably – you’re going to want to calculate job durations to see what is running long, perhaps unexpectedly so.
In certain situations, it may be desirable to make additional documentation available to the user at runtime. SSRS parameters can be leveraged for this purpose.
On occasion there is a need for rows on a report to be conditionally hidden or visible based upon an expression that is determined when the report is run. One example of this type of functionality can be shown within a report displaying the assessments for a patient. Each of the assessments can have a set of questions attached.
This tip is a shout-out to all the reporting folks still working with MEDITECH C/S or Magic from the DR! However, the concepts we’re going to explore apply to 6.x and Expanse as well as any other system where you need to group sets of values and then select one group.
Every so often we need to build a report with a number of complicated calculations that we need to perform at the detail, group or summary level in the report. Maybe we need to calculate some aggregates, then do calculations on the aggregates. Like creating percentage markers for sums of numbers, from multiple groups.
Searching and filtering free text data can be a problem due to human error. Typos, transposed characters and even data entry into the wrong field present a challenge when trying to report on the data. In a SQL query we can use LIKE and wildcards to try to work around these issues.
We recently undertook a project for a customer where we reviewed the top X reports (in terms of usage as logged in SSRS) for performance optimization. Some of their heavy hitters were tying up a lot of DR resources, and slowing things down for everyone.
Because SourceID is part of the primary key in virtually all MEDITECH Data Repository tables, it is good practice to include SourceID as the first column all indexes, include it in all joins and to identify SourceID in the WHERE clause of the query. In most cases this will cause SQL Server to use an index seek instead of an index scan and greatly improve performance.
From time to time in your work in SQL from the DR, you’ll wind up CAST-ing or CONVERT-ing a number into a string. If that number starts as a DECIMAL or NUMERIC with a scale (the number of places of accuracy to the right of the decimal point) then you will wind up with something like this:
- Ever change the logic in your query, confirm new data in SQL, run the report from SSRS… and get the old data?
- Ever change the columns in your query, run the report from SSRS… and get a weird error – or just not get any data in the new column in the report, but you can see it in SQL?
- Even if you click the Refresh button????