Post reply

Functions VS Procedures

  • January 10, 2008 at 10:52 pm

    #181933

    Please, someone explain me, What is the Major Diff. btwn a Function and a Stored Procedure

  • January 11, 2008 at 8:11 am

    #767142

    a function is a special, more limited type of stored procedure. it is specialized, so it has more limitations.

    here's some high points, but there's a lot of infor to google on the subject.

    ··UDF has No Access to Structural and Permanent Tables. (Can't change schemas, like add columns, etc.)

    ··UDF can call Extended Stored Procedure, which can have access to structural and permanent tables. (No Access to regular Stored Procedures)

    ··UDF Accepts Lesser Numbers of Input Parameters. (UDF can have upto 1023 input parameters, Stored Procedure can have upto 21000 input parameters. )

    ··UDF Prohibit Usage of Non-Deterministic Built-in Functions (Functions GETDATE() etc can not be used UDFs, but can be used in Stored Procedure )

    ··UDF Returns Only One Result Set or Output Parameter (

    Due to this it can be used in SELECT statement but can not return multiple result set like Stored Procedure )

    ··UDF can not Call Stored Procedure (Only access to Extended Stored Procedure. )

    ··UDF can not Execute Dynamic SQL or Temporary Tables (

    UDF can not run dynamic SQL which are dynamically build in UDF. Temporary Tables can not be used in UDF as well. )

    ··UDF can not Return XML (FOR XML is not allowed in UDF )

    ··UDF does not support SET options (SET options which can change Server level or transaction level settings are prohibited in UDFs. (SET ROWCOUNT etc) )

    ··UDF does not Support Error Handling (RAISEERROR or @@ERROR are not allowed in UDFs. )

    ··UDF does not Support Print Statements(cannot use PRINT' somevalue to help debug logic)

    Lowell

    --help us help you! If you post a question, make sure you include a CREATE TABLE... statement and INSERT INTO... statement into that table to give the volunteers here representative data. with your description of the problem, we can provide a tested, verifiable solution to your question! asking the question the right way gets you a tested answer the fastest way possible!

  • January 11, 2008 at 9:46 am

    #767209

    One more restriction: UDF's can't modify the DB permanently in any way. So - besides not being able to change the table structure, you also cannot update/insert data.

    On the plus side though, table-valued functions CAN be referenced in much the same way as a table or View. The resulting output is directly usable in selects, etc...

    ----------------------------------------------------------------------------------
    Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?

  • January 11, 2008 at 8:32 pm

    #767375

    UDF's are typically RBAR...

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

  • January 11, 2008 at 10:43 pm

    #767394

    Thank U very Very Much

  • February 21, 2008 at 4:15 pm

    #780903

    Hi

    In many instances you can accomplish the same task using either a stored procedure or a function. Both functions and stored procedures can be custom defined and part of any application. Functions, on the other hand, are designed to send their output to a query or T-SQL statement. For example, User Defined Functions (UDFs) can run an executable file from SQL SELECT or an action query, while Stored Procedures (SPROC) use EXECUTE or EXEC to run. Both are instantiated using CREATE FUNCTION.

    To decide between using one of the two, keep in mind the fundamental difference between them: stored procedures are designed to return its output to the application. A UDF returns table variables, while a SPROC can't return a table variable although it can create a table. Another significant difference between them is that UDFs can't change the server environment or your operating system environment, while a SPROC can. Operationally, when T-SQL encounters an error the function stops, while T-SQL will ignore an error in a SPROC and proceed to the next statement in your code (provided you've included error handling support). You'll also find that although a SPROC can be used in an XML FOR clause, a UDF cannot be.

    If you have an operation such as a query with a FROM clause that requires a rowset be drawn from a table or set of tables, then a function will be your appropriate choice. However, when you want to use that same rowset in your application the better choice would be a stored procedure.

    There's quite a bit of debate about the performance benefits of UDFs vs. SPROCs. You might be tempted to believe that stored procedures add more overhead to your server than a UDF. Depending upon how your write your code and the type of data you're processing, this might not be the case. It's always a good idea to text your data in important or time-consuming operations by trying both types of methods on them.

    Thanks -- Vj

    http://dotnetvj.blogspot.com

    Thanks -- Vijaya Kadiyala
    www.dotnetvj.com
    SQL Server Articles For Beginers


Viewing 6 posts - 1 through 5 (of 5 total)

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