Get And Set SQL Server 2005 Instance Registry Values

  • Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/vIacoboni/3092.asp

  • Was there anything in the PERL script that couldn't be accomplished with xp_instance_regread and xp_instance_regwrite?

     


    My blog: SQL Soldier[/url]
    SQL Server Best Practices:
    SQL Server Best Practices
    Twitter: @SQLSoldier
    My book: Pro SQL Server 2008 Mirroring[/url]
    Microsoft Certified Master: SQL Server, Data Platform MVP
    Database Engineer at BlueMountain Capital Management[/url]

  • Interesting stuff. Couple questions though. Can you post some examples of why you've needed registry access from within SQL? I'm not a PERL user, so is there any advantage to using PERL over the already loaded .Net framework?

  • Andy,

    Are you asking why registry access in general is needed within SQL, or the SQL Server 2005 specific registry keys discussed in the article?

    In some ways, the answer is the same. The registry controls how certain programs interact with their environment. Using SQL Server as an example, it specifies certain paths and options, such as the backup path and port options discussed in the article. If you want these options tweaked, you must either use sanctioned front-ends (assuming they are exposed there) or some kind of utility to do so. In my environment, getting those paths and options to be consistent across multiple instances was important enough that I wrote this utility.

    For example, the backup path specifies where files will go if they're not fully qualified. This can make it much easier to backup using a DISK= statement.

    Does that answer your question?

  • Sorta, maybe wasnt the best question either. Are there things you're able to change this way that you can't using SMO or DMO?

  • Andy,

    I'm not very familiar with SMO or DMO, but you can only work with what portions of the object model are exposed. BackupDirectory is an exposed property, with warnings not to use it. I didn't see any properties for ports. Of course, SMO and DMO have the advantage that they are documented and supported better than registry keys.

    For me, I'm comfortable with Perl and the registry so this was my way to solve the issue. I can see that others might prefer a SMO approach.

  • Your list doesn't include the DefaultData and DefaultLog entries in it.

    These are the only values I read or set on a regular basis:

    Exec

    xp_instance_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'BackupDirectory'

     

    Exec xp_instance_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultLog'

     

    Exec xp_instance_regread N'HKEY_LOCAL_MACHINE', N'Software\Microsoft\MSSQLServer\MSSQLServer', N'DefaultData'


    My blog: SQL Soldier[/url]
    SQL Server Best Practices:
    SQL Server Best Practices
    Twitter: @SQLSoldier
    My book: Pro SQL Server 2008 Mirroring[/url]
    Microsoft Certified Master: SQL Server, Data Platform MVP
    Database Engineer at BlueMountain Capital Management[/url]

  • Thanks, Robert, I'll add them in.

  • If Microsoft.VisualBasic.Right(hpServerName.ToUpper, 1) = "C" Then

    Dim rk As RegistryKey = RegistryKey.OpenRemoteBaseKey(RegistryHive.LocalMachine, _

    hpServerName).OpenSubKey("Software\Microsoft\Microsoft SQL Server\MSSQL." & strX & "\Cluster")

    Dim Instances As String

    Instances = rk.GetValue("ClusterName")

    To all those who want to do the Perl script in net code behind.

  • Vince, SQLArg0 will have the first startup option, no matter which one it is. You need check each possible one until the desired startup option is found or the key does not exist. It's annoying. There can several options (e.g., trace flags). SQLArg0,..., SQLArg10,....

    Andy, if you have more than a few dozen SQL Servers, it helps to use these tools to standardize the installation and setup via scripts. The GUI leaves too much room for mistakes by large teams. It's also easier to just run the script. There is a SMO Setting class of some sort, but I think it has a warning that it's going away in a future version. I'm stickin' with the xp version until I'm forced to do otherwise. It's nice when something does not have to be fixed with each version - getting too old for much more of that.

    RandyHelpdesk: Perhaps Im not the only one that does not know what you are doing. 😉

Viewing 10 posts - 1 through 9 (of 9 total)

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