fn_fixeddrives() : an alternative for xp_fixeddrives

  • Thanks - this was a good article. It is nice to see stuff like this in CLR.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • Hi David,

    I appreciate the concept but I have to disagree with the approach. We programmers can come up with a lot of "nice" solutions, but they don't always work in the corporate world. This is a factor you haven't touched on in your article.

    Remember, we have total control over our PC with our local SQL, but in large enterprise environments, the situation is completely different.

    Your solution is not so practical because -

    * I don't have access to the server's local drive - I need it to be able to copy the DLL.

    * I am not allowed to even turn on the CLR option.

    * The function is unsafe and in corporate environments I just don't have the permissions to install it.

    * DBAs frown upon CLR.

    I can come up with more reasons, but you get the idea.

    Now, it so happens that I needed the same feature just last week.

    I implemented it in PURE SQL using just one short stored procedure. Similar code has been out there for some time. I tweaked it for my needs. I think it is generic enough to be used by anyone.

    I named it sp_fixeddrives and put it in master. This enables me to call it from any db.

    I also created a job that executes it hourly, and checks the free space %. If it falls below a threshold, I send out an alert email.

  • SQueaLer1 (9/21/2010)


    Hi David,

    I appreciate the concept but I have to disagree with the approach. We programmers can come up with a lot of "nice" solutions, but they don't always work in the corporate world. This is a factor you haven't touched on in your article.

    Remember, we have total control over our PC with our local SQL, but in large enterprise environments, the situation is completely different.

    Your solution is not so practical because -

    * I don't have access to the server's local drive - I need it to be able to copy the DLL.

    * I am not allowed to even turn on the CLR option.

    * The function is unsafe and in corporate environments I just don't have the permissions to install it.

    * DBAs frown upon CLR.

    I can come up with more reasons, but you get the idea.

    Now, it so happens that I needed the same feature just last week.

    I implemented it in PURE SQL using just one short stored procedure. Similar code has been out there for some time. I tweaked it for my needs. I think it is generic enough to be used by anyone.

    I named it sp_fixeddrives and put it in master. This enables me to call it from any db.

    I also created a job that executes it hourly, and checks the free space %. If it falls below a threshold, I send out an alert email.

    Any chance of you posting your tweaked code for this? I'd love to see the T-SQL alternative to such as this. Thanks.

    --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)

  • SQueaLer1 (9/21/2010)


    Hi David,

    I appreciate the concept but I have to disagree with the approach. We programmers can come up with a lot of "nice" solutions, but they don't always work in the corporate world. This is a factor you haven't touched on in your article.

    Remember, we have total control over our PC with our local SQL, but in large enterprise environments, the situation is completely different.

    Your solution is not so practical because -

    * I don't have access to the server's local drive - I need it to be able to copy the DLL.

    * I am not allowed to even turn on the CLR option.

    * The function is unsafe and in corporate environments I just don't have the permissions to install it.

    * DBAs frown upon CLR.

    I can come up with more reasons, but you get the idea.

    Now, it so happens that I needed the same feature just last week.

    I implemented it in PURE SQL using just one short stored procedure. Similar code has been out there for some time. I tweaked it for my needs. I think it is generic enough to be used by anyone.

    I named it sp_fixeddrives and put it in master. This enables me to call it from any db.

    I also created a job that executes it hourly, and checks the free space %. If it falls below a threshold, I send out an alert email.

    Hi,

    Thank you, this was the comment I was hoping to read

    I understand your position, but because I use this in an operationnal monitoring tool for a while on many business critical environments, I cannot agree on all points. It really depends on your role in the database infrastructure. I am considered as the DBA on the systems I monitor for my clients, so I am pretty much on my own to apply the method I want, but this is not the point.

    The problem is because SQLCLR is not so well understood by the DBAs in general. And for a DBA, who carries the responsability of the corporation's data management and safety, what is not so well understood will wait on the doorway until it is, if not thrown away. I've been a production DBA for the past 10 years, I know how conservative we can be with new *cool* features.

    The message I tried to send under the covers was that SQLCLR exists, and to use it you must understand what it can do and what it can't. There is a hazard that comes with practically every tool but it is not a valid reason for me not to learn from it. Same thing applies to COM automation in SQL Server, which is fantastic tool, but because the warnings have always been a square mile big, very few people uses it.

    Because of all these assumptions, SQLCLR is still in its infancy, like LINQ for example which already turned DBAs against it even before it had touched the market floor. This is why sqlclr.net exists and we try to show the guys in control SQLCLR is not that evil. I know this is a long way to convince DBAs it is better to build bridges across production IT and developpers, but we'll hold. 😀

    Thanks again,

    PS: Like Jeff, I'd also be interested in seeing how you can achieve this using standard T-SQL.

    David B.

  • David BAFFALEUF (9/22/2010)


    The problem is because SQLCLR is not so well understood by the DBAs in general. And for a DBA, who carries the responsability of the corporation's data management and safety, what is not so well understood will wait on the doorway until it is, if not thrown away. I've been a production DBA for the past 10 years, I know how conservative we can be with new *cool* features.

    Truer words rarely spoken. I think the SQL Server community as a whole is very slow to adopt new technology - which can be frustrating. However, it's probably that same characteristic that has made it one of the longest serving job skills in the IT industry as a whole...

    Atlantis Interactive - SQL Server Tools
    My blog[/url]
    Why I wrote a sql query analyzer clone

  • I wonder if you could point me towards a PowerShell implementation of this function? It may not be an option to compile DLL's or switch on CLR in some environments.

  • Hi Siraj,

    Yes you can call:

    [font="Courier New"][System.IO.DriveInfo]::GetDrives() | Format-Table [/font]

    ...from the powershell prompt.

    David B.

  • Thanks for the article, it has helped me better understand how to create CLR functions.

    The discussion is very good as well, so thanks again to everyone!

  • David,

    I really appreciate the article. I've always wanted to learn about SQLCLR and your concise (yet useful) example was just the thing to motivate me into trying it. The code compiled cleanly in VS2010, but I've encountered a number of issues with getting this built on my SQL Server 2008 environment.

    For some reason, I had to SET compatibility_level = 90. I had copy the .DLL to the MSSQL\Binn folder before the CREATE ASSEMBLY command could find it and open it. (Probably folder access permission issue.)

    I got "stuck" at the CREATE FUNCTION step. I receive a Msg 6505 - Could not find Type 'cFixedDrives' in assembly 'cFixedDrives'. Then I found a KB article on MSDN which advised that I need to include the namespace qualifier as in the following example:CREATE FUNCTION fn_fixeddrives ()

    RETURNS TABLE(

    "Drive" nvarchar(3),

    "Size(Mb)" bigint,

    "Used(Mb)" bigint,

    "Available(Mb)" bigint,

    "Use%" bigint

    )

    AS EXTERNAL NAME fixeddrives.[cFixedDrives.cFixedDrives].fn_fixeddrives

    GO

    I have a couple of other questions related to this SQLCLR stuff though. I notice that I can only execute this new function in the database I was in when I created the function. Is there a way that I can cause this to work no matter which database I'm in? Can I include more than a single function in the assembly? (For example, I'd like to code up a bunch of validation routines for various columns in our databases and I was wondering if each one had to be created separately or if I can compile a single .DLL which contained them all.)

    Again David, I learned quite a bit from this article and it's got me thinking about all of the possibilities I might be able to use this for. Thanks!

  • You can have any number of function/procedures in within a DLL.

    If you need to call the function from another database use the fully qualified name of the function

    eg:- [databasename].[schemaname].fn_fixeddrives()

  • Hi Larry,

    Thanks for your comments,

    As blessonblessons says, you'll have to use the fully qualified name to be able to call the function from any other database.

    It had been a stored procedure instead of a function, you would have been able to create it in the master database and to turn it as a system object using sys.sp_MS_marksystemobject, making the object callable from any database without fully qualifying the name, but it looks like this cannot apply to functions 🙁

    David B.

  • David BAFFALEUF (9/24/2010)


    Hi Larry,

    Thanks for your comments,

    As blessonblessons says, you'll have to use the fully qualified name to be able to call the function from any other database.

    It had been a stored procedure instead of a function, you would have been able to create it in the master database and to turn it as a system object using sys.sp_MS_marksystemobject, making the object callable from any database without fully qualifying the name, but it looks like this cannot apply to functions 🙁

    You can make just about anything work from the Master database just by giving it the prefix of sp_. sp_ does not, contrary to popular belief, stand for "Stored Procedure" here. It stands for "SPecial".

    Also, with the advent of synonymns, I avoid using any naming convention other than 2 part naming conventions so that if the database name changes (for any reason) or I need to move code to another server, I don't have to find all the 3 part naming convention stuff and change it. I only need to modify a handfull of synonyms.

    --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)

Viewing 12 posts - 16 through 26 (of 26 total)

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