For today's blog post, we want to help solve this common problem: how to clean up custom objects like #Temp or ##Temp tables in a SQL database when they are no longer needed.

Introduction

As we create custom objects in a SQL database like the DR, we need to be mindful of cleaning them up when they are no longer needed, or when we need to clear an old object out, before re-creating it.

There is lots of data stored in MEDITECH data, but invariably you are going to encounter that one bit of data that you need, that is not helpfully stored in the tables you are using.

As we go through our daily lives of reporting and analyzing data, we use SELECT constantly. It’s like breathing after a while… and while we might be keeping an eye on the performance of our queries, so that we don’t use unnecessary system resources, they generally don’t crash out on a resource constraint issue and interrupt other processes. SQL Server is good at managing them.

In a modern hospital environment, you inevitably have multiple applications holding disparate sets of data. But that data is often related to the data in other systems, and sooner or later (generally sooner) someone is going to ask you something like:

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!