Get path of SYSTEM32 directory

Hello all, i have a little problem...

...Is there any method for getting the path of the SYSTEM32 directory from a stored procedure?

I need it for register an assembly that is in this directory or the server.

Thanks.

Alejandro F.

In SQL Server 2005, I would use the CLR to do this. You would have to mark it as unsafe allowing external access, but then you could just use .NET's native functionality to get the value.

|||

Thanks, but I need the path of system32 directory for registering my DLL with my CLR functions.

It’s any way to register a DLL without specify the entire path of the DLL?

Sorry about my English…

|||

No, but what I was suggesting was to build a CLR function (that you will be building and deploying manually) and use a windows API type call to get the path of system32.

Since this directory doesn't change, why not just have a configuration table that you put the path into? That would be easiest.

|||It's not a bad idea, thanks for all.|||

Consider doing these type of operations outside of the database? What is the purpose of this task? Is it an administrative routine? How often does it run? Do you really need to enable CLR or xp_cmdshell for such simple operations? Who runs these operations? For example, if you are creating assemblies using a script then it is trivial to obtain the path using various client-side techniques. It takes more programming and manageability to do even simple operations that require access to OS resources. And not to mention the security implications.

So if you have a choice keep TSQL for operations it can do best. I usually find it strange when people try to use TSQL to solve every problem. For example, in a CMD script you need to just reference %windir%\system32 - this assumes you run the script on the server. Now, if you want to do the same using TSQL then you need to enable xp_cmdshell, create temporary table, insert results into temporary table, read from temporary table, check for errors etc. The CMD script approach is more robust easy to execute on server, isolates higher-privilege operations, easy to modify (what if you later want to deploy assemblies by synching from your source code control system on different server) and so on.