July 3, 2007 at 9:52 am
Comments posted here are about the content posted at http://www.sqlservercentral.com/columnists/vIacoboni/3092.asp
July 30, 2007 at 9:56 pm
Was there anything in the PERL script that couldn't be accomplished with xp_instance_regread and xp_instance_regwrite?
July 31, 2007 at 5:24 am
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?
July 31, 2007 at 6:54 am
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?
July 31, 2007 at 7:28 am
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?
July 31, 2007 at 7:40 am
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.
July 31, 2007 at 11:45 am
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'
July 31, 2007 at 11:53 am
Thanks, Robert, I'll add them in.
October 12, 2007 at 9:27 am
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.
November 3, 2008 at 7:06 pm
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