I spent some time this week tightening up the code in a project that will actually be released into the wild. I wanted to make sure that I catch as many errors as possible and put up user friendly messages.
The program uses SMO and RMO to synchronize a local SQL Express database with a master database over the internet. The program would get some pretty cryptic error messages if SQL Express wasn’t installed, if the expected instance weren’t available or if the replication components weren’t installed.
I was easily able to check if SQL Express was installed and to get a list of the installed instances, but I couldn’t find a way to check if the replication components were installed. This was annoying because the replication components aren’t installed by default when SQL Express is installed and I was assuming that this situation would come up often.
After some refactoring, I was able to get it to throw an exception with a pretty straight forward error message: “Replication components are not installed on this server. Run SQL Server Setup again and select the option to install replication.” In fact, I could catch the exception and put up whatever error message I wanted. Unfortunately, this exception would not occur until the program spent quite a while preparing to do the synchronization. I really wanted to check for the replication components before I attempted any synchronization.
I spent quite a while googling trying to find something that would work, but couldn’t find anything. Then I tried checking for the existence of several stored procedures, tables and entries in the SysObjects tables, but nothing I found on a server with the replication components was missing on one without them.
Then I came across the sp_MS_replication_installed system stored procedure. It’s on all installations and tells exactly what I needed. I was surprised that with all the searching I did, there was no mention of this handy stored procedure, so I figured I would do my part and document what I found.
The stored procedure is simple enough in that it returns a 0 if the replication components are installed and a 1 if they aren’t. However, under usual circumstances, it goes a step further and raises an exception if the components aren’t installed. This is because the procedure reads an entry in the registry to see if the replication components are installed and if they aren’t, it is likely that the entry was never written in the first place. When it can’t find the registry entry, an exception is thrown. The only time the stored procedure would return a 1 without throwing an exception is if the replication components were installed at some point and then later uninstalled.
I could use the sp_MS_replication_installed stored procedure as is and catch the exception when it got thrown, but I really don’t like code that relies on exceptions to operate correctly. Exceptions should be just that – the exception.
I took a look at the sp_MS_replication_installed stored procedure and found that all it is doing is calling xp_instance_regread and doing error handling. Since I didn’t like the error handling that sp_MS_replication_installed was doing, I figured I would call xp_instance_regread myself and do my own error handling.
I changed the replicationInstalled function to call xp_instance_regread directly. If the registry key exists, the @IsInstalled parameter returns the value from the registry. That value tells whether the replication components are installed. If there is no value in the registry, the @IsInstalled parameter returns a null. I take the value of @IsInstalled and check to see if it is null. If it is null, I return false. If it is not null and it is indeed an integer, I return that integer.
Using the new replicationInstalled function my program is able to quickly check if the replication components are installed before attempting to do any synchronization and without throwing any exceptions. Mission accomplished!