It is rare that this will come up, but in certain circumstances you may need to change (or guarantee) the database in which a query executes.
This can really plague you when you’re working with multiple databases on multiple servers. You don’t want to forget which database you’re in… and execute code in the wrong place.
One day you write some code on a new system, or using tables in the database you’ve never used before, and BOOM! A perfectly ordinary query blows up… what is this collation business??!
Ignore SourceID at your peril!
When creating joins in a SQL query, best performance is often attained by including as many primary key columns in the JOIN predicates as possible. In Meditech’s Data Repository, the SourceID column is often overlooked, especially by SQL newbies. SourceID is the first primary key column in virtually every table in Data Repository databases and simply adding this column to your joins can improve performance dramatically.
For today's blog post, we want to help solve this common problem: how to limit the number of columns in a matrix to prevent it from exceeding the page width, when there may be any number of columns.
The following information is based on Limit no of columns in SSRS matrix report By Challen Fu, Microsoft.
MEDITECH stores a lot of bulk text in the DR; usually as a sequenced table of lines, with some line length. That text may or may not be formatted with extra characters to control fonts and bold/italic/etc.
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:
Comments