CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Raymond Lewallen

Framework Design, Agile Coach, President Oklahoma City Developers Group, Microsoft MVP C#, TDD, Continuous Integration, Patterns and Practices, Domain Driven Design, Speaker, VB.Net, C# and Sql Server

Manipulating the registry using T-SQL

Well, after a 3 week vacation from blogging, I’m back.  The past month has been very busy for me, but its time I get back on track.

So I had somebody send me some code that they were having problems with.  They were trying to use T-SQL to read a value from the local registry.  When I saw that the code was about 70 lines long, I didn’t even really examine it, as there is a much easier way to get values from the registry.

In the master database, there is an extended stored procedure called “xp_instance_regread” that allows you to read values from the registry.  The reason most people don’t know about it is because you won’t find any information in BOL.  If its undocumented, this means that they are unsupported by Microsoft and you have to google to figure out how to use them, or ask somebody who knows.

Here is a quick example on using xp_instance_regread to get the installation path of Sql Server, and another one that tells you where the default data directory is for Sql Server.

declare @returnvalue int,

@path nvarchar(4000)

exec @returnvalue = master.dbo.xp_instance_regread N'HKEY_LOCAL_MACHINE',N'Software\Microsoft\MSSQLServer\Setup',N'SQLPath', @path output, 'no_output'

print @path

 

go

 

declare @returncode int,

@path nvarchar(4000)

exec @returncode = master.dbo.xp_instance_regread N'HKEY_LOCAL_MACHINE',N'Software\Microsoft\MSSQLServer\MSSQLServer',N'DefaultData', @path output, 'no_output'

print @path

In addition to an extended stored procedure to read values from the registry, there are other xp’s that allow you to manipulate the registry as well.

  • xp_instance_regaddmultistring
  • xp_instance_regdeletekey
  • xp_instance_regdeletevalue
  • xp_instance_regenumkeys
  • xp_instance_regenumvalues
  • xp_instance_regremovemultistring
  • xp_instance_regwrite

As always, use these extended stored procedures with EXTREME CAUTION!  Also, anybody can use xp_instance_regread, but you have to be in the sysadmin role to change, write and delete registry values and keys.



Comments

Jeffrey Palermo said:

This must be a specialized program of some sort for it to _have_ to read a registry value from T-SQL.

Thanks for this comprehensive information about these extended stored procedures. I hope I never need them!
# September 13, 2005 8:35 AM

Raymond Lewallen said:

LOL JP. I don't use them myself (have on rare occasion wrote to reg though when installing mutliple instances of sql server programmtically), but there are people who do. Most people use them to do nothing more than read particular path information related to sql server, like log file directories, installation path, data directory etc. They even are shipped with 2005, so people are depending on them still.

Sorry I didn't elaborate more on them (taking your comprehensive information remark as sarcasm :D ). I just wanted people to be aware they existed, and not necessarily detail out their use as to give the impression I'm an advocate of people using them.
# September 13, 2005 11:25 PM

Seattle Web Design said:

No one big problem that I haven't been able to solve, is that I need to test if a registry key exists. The problem with these undocumented procs is that they don't through error code. I can check if a key exists or not by running the xp_regread in the UI, but I cannot do it from my stored proc because it will through an error message from the platform API. It will be great if they can wrap the error message from the platform API to the T-SQL error code, but anyway, this is unsupported procs...
# October 20, 2005 3:43 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Raymond Lewallen

Working primarily in the public sector during his career, Raymond has designed and built several high profile enterprise level applications for all levels of the government. Raymond now works as a solutions architect for EMC. Raymond is an agile coach, Microsoft MVP C# and also president of the Oklahoma City Developers Group and Oklahoma Agile Developers Group. Raymond spends a lot of his time learning and teaching such things as Test Driven Development, Domain Driven Design, Design Patterns and Extreme Programming practices and principles, to name a few. Raymond is also an advocate of Alt.Net. Raymond is primarily a framework guy, so don't ask him anything about UI :) Check out Devlicio.us!