Essentially every table that you access in the Meditech DR has a SourceID field embedded as part of the primary key. If you are a single facility system, you generally wind up having only a single value for your SourceID across all tables and modules.
As you work with Meditech BAR 6.15, you may find yourself needing to identify the GL Account that a payment or adjustment posts to. And then… you find that the appropriate field in the non-charge procedure dictionary has a dynamic string definition stored in it, instead of a specific GL Account number.
As you work with calculations in SQL, eventually you’re going to get caught up (particularly when trying to output the data to a file, for a vendor) by the T-SQL rules around maintaining a proper number of significant digits in the results of a calculation. Generally speaking, SQL does not want to lose any validity in the data, so it is going to expand the number of significant figures to “keep” everything.
One of the upsides / downsides of deploying SQL Server Reporting Services to your customers is that it allows them to Export data from a published report (or a subscription to a report) to a file. You can also send the data by email, though that functionality is disabled by default.
T-SQL contains within it a module which lets you generate XML data directly from SQL. No concatenating strings or building the XML layout by hand required!
Over the (relatively) long history of T-SQL and SQL Server, when we (as programmers) needed to format a date or a number inside our SQL we primarily had access to two commands:
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.