Linked Server and Synonym

Last Friday, I needed to compare the content of both the DEV and QA databases as a preparation for a QA deployment. My machine just got a fresh image so I didn’t have the database tools that could have made the task a breeze. I had to finish ahead of the deployment so instead of rummaging for the installer of the tools, I decided to improvise. Good thing, they were just few reference tables which usually have few columns.

In order to accomplish my task, I should be able to connect to the QA database in a remote machine and query the equivalent tables together local ones in a single query. But SQL Server has no innate ability to query database from other machine. You connect to that machine using the feature called Linked Server. It’s not going to be a smooth procedure though per my experience but the solution is not too complex to stymie anyone. Once connected, you can query the pertinent tables and here, another feature called Synonym, first introduced in SQL Server 2005, can offer a little convenience.

So the first step is to create a linked server. One way to accomplish this is by right clicking the Linked Servers under the Server Objects node and selecting “Add New Linked Server…”. In my case, I was connecting only to a SQL Server instance so in the General Page all I needed to specify was the name of the instance. Be aware that this is not an arbitrary value when connecting to a SQL Server instance. It has to be the name of the instance.

Next is to configure the security aspect. The objective here is to specify a local login which will be mapped to another login in the remote server so that whenever you use the linked server, you actually use a proxy login in the remote server with the correct privileges. If both servers are located in the same machine, you can simply add any login with correct privileges and check “Impersonate” as shown below. This is a good practice since you’re controlling who gets access to the remote server.

Applying the setting above in a remote server in an Active Directory however, produces this vague error message:

I have no idea where the heck this “NT AUTHORITY\ANONYMOUS” account comes from so I googled the last sentence which, as you can see, is pretty much generic. Not surprisingly, the result was a myriad of situations on almost anything that involves NT authentication. Among them, this one, in my opinion gives the closest semblance to my predicament. Although the KB is applicable only to SQL Server 7.0, I still tried the solution. Mapping the local login didn’t work either so I ultimately settled for SQL Server-authenticated account to establish the security context. I skip the mapping list altogether so the configuration dialog should then contain only values similar to the ones below:

After establishing the linked server, one can proceed to cross database query like this:

If you perform considerable number of queries on the remote server, you can leverage on Synonym which can spare you some keystrokes and make the queries a tad shorter. This is because with Synonym, you can create alias on certain objects of the remote database. You create a synonym in the “Synonym” node of your database. With my linked server, a synonym configuration would look like this:

The only arbitrary field is the name. Everything depends on the properties of the local and remote database. You can also create synonyms for other objects like function, stored procedures and view. Note that the account used by the linked server should have the needed privileges to the concerned object in order to succeed with the creation. With that taken cared of, the previous query then becomes:

Like any other database objects, Synonym is “securable” meaning you can control who gets to do what on it. This can be done in the Permission page of the Create Synonym dialog as shown below. First I thought this can be used to grant access for logins other than the one used in the linked server but based on my investigation, it looks like it’s dependent on the linked server logins. This means you cannot grant access on a synonym to a login unless it is also capable of connecting to the linked server. For safety reasons, I would have loved it if I could let a developer access a synonym but not the linked server.

Obviously this not the most efficient way of comparing data between two identical databases but sometimes when you do things manually, you would be compelled to explore some hidden features in a technology. Who knows, those features might come handy for tasks where tools for achieving them are not there yet.