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????
Despite all our best efforts, occasionally – rarely – perhaps inconceivably – there are problems with reports or extracts we create for our end users.
Recently while working a regulatory report I found myself faced with needing to identify the first (or earliest) of a set of dates. Each date came from a different possible order related to the patient visit, and I needed to chunk through 10 different JOIN-ed tables and get the one with the first / earliest date.
When we’re working on other people’s code – for troubleshooting or optimization purposes – we see a fair amount of usage of the ISNULL() function. Generally speaking we replace those ISNULL() references with COALESCE().
Once you start working with Microsoft’s reporting solution, you will find there are multiple versions of SSRS, and some of the versions have different specifications for the RDL files which hold your report definitions.
In addition, there are different versions of Report Manager (and the rendering engine) which have different capabilities. And you can also publish RDL’s through SharePoint.
SQL Server Integration Services is a powerful tool for building a single DTSX package, which can generate a single output file — or dozens of them — and let that set of work be scheduled to run automatically. And it’s included in your MEDITECH Data Repository server license for SQL Server! Instead of a dozen NPR reports, each with its own schedule (or the same setup using SQL and bcp’ing out files), you can have one .DTSX package that calls a stored procedure per file you need.
Which is all fantastic, until you find that you need a #temp table for some kind of multi-step processing inside your stored procedure…
A very useful tool to have in your Data Repository toolbox is a Date Dimension table — which is a physical database table with one row per date from, say, 1900 through the end of 2499, and key elements pre-calculated about that date.