SQL Instance Aliases - Urgent assistance needed please

Question

SQL Instance Aliases - Urgent assistance needed please

November 1, 2021 at 2:13 am

This was removed by the editor as SPAM
December 31, 2021 at 2:22 am

This was removed by the editor as SPAM

Viewing 4 posts - 16 through 18 (of 18 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1003863 More actions · Answer 1

I don't know much about how they did it because I never get to see the code but the devs where I work only have 1 connection configuration for each app no matter how much code is in the app. I don't know if that's how you're setup or not but it only takes our folks minutes to change the connections (which we had to do a couple of times).

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Mr. Brian Gale SSC-Insane Points: 24690 More actions · Answer 2

Jeff - your approach is what our devs (myself included) are migrating to (I think). Basically, the connection string gets stored in a settings file that is read on app launch. This way, if an instance name changes or the alias breaks, we can just update the .settings file to the proper name and no need to recompile. 1 change per app unfortunately, but we don't need each and every app connecting to each and every database.

An alternate approach could be to use a DLL instead of the settings file and that DLL gets stored on a shared location on the network and all apps reference it. Then if a connection string needs updating, you update the DLL and the apps are updated automagically without a recompile.

In general - I advise against hard coding any values that are referencing external systems. It is far too easy for a system to claim to never change and then it does. I remember a few years back a headache we had when we changed domain names. We were told nothing should break, and all our SQL Service accounts got new auto-generated passwords and the servers didn't get updated password so all our SQL instances failed to come back up after reboot. That one would be harder to prepare for, but any code we have that relies on AD has a configuration option for all of the AD settings now so a change in AD doesn't need a full recompile.

The above is all just my opinion on what you should do.
As with all advice you find on a random internet forum - you shouldn't blindly follow it. Always test on a test server to see if there is negative side effects before making changes to live!
I recommend you NEVER run "random code" you found online on any system you care about UNLESS you understand and can verify the code OR you don't care if the code trashes your system.