How can I conditionally use a linked server depending on the environment a stored proc is currently running in? - sql-server-2005

Question

Here's the issue I'm having. I am trying to create a stored proc that will be deployed to DEV, QA, and PROD environments. Because of the strict requirements on the deployment process, I have to make sure my proc in the same across all three environments and has to work (of course!). The problem is that this proc references a table in a different database. In DEV and QA this is ok, because the database is on the same server, however in PROD the database in question is located on a separate server. The following is a code snippet from my proc that tries to deal with the different environment issues:
IF ##SERVERNAME<>'Production'
BEGIN
select distinct m.acct_id
from l_map m (nolock)
join #llist ll on ll.acct_id = m.acct_id
where ll.acct_id not in (select l_number from [OTHERDATABASE].[dbo].[OTHERTABLE] where lmi_status_code not in (select item from #ruleItems))
END
ELSE
BEGIN
select distinct m.acct_id
from l_map m (nolock)
join #llist ll on ll.acct_id = m.acct_id
where ll.acct_id not in (select l_number from [OTHERSERVER].[OTHERDATABASE].[dbo].[OTHERTABLE] where lmi_status_code not in (select item from #ruleItems))
END
My proc is called from within a different proc. When I test the above logic directly, I get the results I expect. However, when I try to test it in context in DEV or QA (from the top level proc), I get an error saying that [OTHERSERVER] could not be found. I cannot (and don't need to) create a linked server in DEV and QA, but I need to be able to use the linked server in the PROD environment. Does anyone know how to accomplish this?

Answer 1

Use synonyms, see here.
Also see these two SO examples: one, two.
Synonym definition on each server may be (is) different, but the code (stored procedure) does not change.

Answer 2

My suggestion is to create a view on the table in the linked server. On your test server you can create a view onto a local table with test data.
In this way information about the linked server is isolated to the view. Then you can write your stored proc or other queries referencing the view, rather than referencing the linked server directly.
Note that this will not enable you to test the security and permissions you need, only that the query works with the schema.

Answer 3

I have the same situation.
Using an alias, I can not use OpenQuery that I need to execute functions with parameters on the destination server, where a simple SELECT INTO or EXECUTE was not possible.
Using EXEC will return (using my configuration) in error Msg 7411:
Server 'linked_server_name' is not configured for RPC.
Here is an example of my approach using a string query. Note that on testing I don't use linked server but you can use one if you need:
-- Prepare Source Query Fragment
IF ##SERVERNAME = 'production_server'
SET #SelectQuery = ' OPENQUERY (['
+ #SourceServer + '],''EXEC [production_source_db].[schema_name].['
+ #FuncrionName+'] '''''
+ #param_1 + ''''', '''''
+ #param_2 + ''''''')';
ELSE
SET #SelectQuery = ' EXEC [testing_schema].['
+ #FuncrionName+'] '''
+ #param_1 + ''', '''
+ #param_2 + ''')';
-- Prepare Destination Query Fragment
IF ##SERVERNAME = 'production_server'
SET #Destination = '[production_destination_server].[production_destination_db].[schema_name]';
ELSE
SET #Destination = '[testing_schema]';
-- Execute the data transfer
EXEC ('
INSERT INTO ' + #Destination + '.[Destination_Table] (
[Col1]
, [Col2])
SELECT
[Col1]
, [Col2]
FROM ' + #SelectQuery )