Question

Here's our scenario.

We successfully migrated our SharePoint 2010 Foundation databases to another server using this method and this article. The key point is that we set up an alias from our existing SQL Server (let's call it "SQL1" for this post) to the new SQL Server (let's call it "SQL2") for this post, per the best practice in the article.

The problem is, we have some custom databases on "SQL1" that are used by web parts (don't ask why: legacy code). Those web parts look in the web.config for the original SQL Server name "SQL1", which now has an alias on it.

Since we only migrated the SP environment databases, these custom DBs weren't moved, so now we get errors saying that the custom databases could not be found, because the alias points to "SQL2", where the custom DBs don't exist. How can we get around this without moving the custom DBs? Is it possible to add multiple aliases on "SQL1" to point back to itself (sounds crazy, I know)?

Was it helpful?

Solution

Keep your ALIAS as is. In your web.config change all your connection strings for your custom web-parts/apps to point to the IP address of the SQL server.

OTHER TIPS

If you are able to identify which web.config settings should point to SQL1 and which should point to SQL2 then you should change the respective values to point to the correct alias (yes you can have both SQL1 and SQL2 aliases side-by-side pointing to different database servers).

However, you can't route SQL traffic to a specific server from one alias. Think of them as "dumb" pointers. Also, aliases only operate at a server level, you cannot configure them per-database.

Licensed under: CC-BY-SA with attribution
Not affiliated with sharepoint.stackexchange
scroll top