Using T-SQL to Modify Functions
You can use the ALTER FUNCTION command to change a function’s definition without having to drop and re-create it. The syntax for the ALTER FUNCTION command is identical to the syntax for CREATE FUNCTION, except that you replace the CREATE keyword with the ALTER keyword. The following example modifies the AveragePricebyType2 function:
ALTER FUNCTION AveragePricebyType2 (@price money = 0.0)
RETURNS @table table (type varchar(12) null, avg_price money null)
with schemabinding
AS
begin
insert @table
SELECT type, avg(price) as avg_price
FROM dbo.titles
group by type
having avg(price) > @price
order by avg(price) desc
return
end
Using the ALTER FUNCTION command has a
couple advantages over dropping and re-creating a function to modify it.
The main advantage, as mentioned earlier, is that you don’t have to
drop the function first to make the change. The second advantage is
that, because you don’t have to drop the function, you don’t have to
worry about reassigning permissions to the function. To determine
whether a function has been altered since it was created, you can query
the LAST_ALTERED column in the INFORMATION_SCHEMA.routines view for that function.
One limitation of the ALTER FUNCTION command
is that you cannot use this command to change a table-valued function
to a scalar function or to change an inline function to a multistatement
function. You have to drop and re-create the function.
Using SSMS to View and Modify Functions
To view or edit a function within SSMS, open the
Object Explorer to the database in which you want to create the
function. Then select the Programmability node, right-click the Functions
node, and then select either the Table-Valued Functions folder or the
Scalar-Valued Functions folder. SSMS then displays a list of the
functions of that type defined in that database within the Object
Explorer as well as in the Summary window.
Note
If the function you want to view or edit is not shown
in the list, it was probably created after the list of functions in the
Object Explorer was populated. You might need to refresh the function
list in Object Explorer. To do this, you right-click the Functions folder and choose Refresh.
When you right-click a function name in either the
Object Explorer or the Summary window, you are presented with a number
of options for viewing or modifying the function, as shown in Figure 5.
You can view or edit the function properties, view
the function dependencies, delete the function, rename it, modify it, or
script the function definition. If you choose to edit the function by
clicking Modify, SSMS opens a new query window with the source code of
the function extracted from the database as an ALTER FUNCTION command. You can edit the function as needed and execute the code in the query window to modify the function.
There are also options for scripting a function as a CREATE, ALTER, DROP, or SELECT command to either a new query window, a file, or the Clipboard, as shown in Figure 6.
You can also view the function properties by
selecting the Properties option from the context menu. The Properties
dialog appears, as shown in Figure 7. Unfortunately, except for the function permissions and extended properties, the properties shown are read-only.
3. Managing User-Defined Function Permissions
When
a function is initially created, the only user who has permission to
execute the function is the user who created it. To allow other users to
execute a scalar function, you need to grant EXECUTE permission on the function to the appropriate user(s), group(s), or role(s). For a table-valued function, you need to grant SELECT permission to the user(s), group(s), or role(s) that will need to reference it. The following example grants EXECUTE permission on the getonlydate() function to everyone and SELECT permission on the AveragePriceByType function to the database user fred:
GRANT EXECUTE on dbo.getonlydate to public
GRANT SELECT on AveragePricebyType to fred
In SQL Server 2008, you can also specify the
execution context of scalar-valued and multistatement, table-valued,
user-defined functions. Essentially, this capability allows you to
control which user account is used to validate permissions on objects
referenced by the function, regardless of what user is actually
executing the function. This provides additional flexibility and control
in managing permissions for user-defined functions and the objects they
reference. Only EXECUTE or SELECT permissions need to
be granted to users on the function itself; you do not have to grant
them explicit permissions on the referenced objects. Only the user
account defined as the execution context for the function by the EXECUTE AS clause must have the necessary permissions on the objects the function accesses.
For example, in the following SQL script, the AverageBookPrice2 function is modified to run within the context of the dbo user. Any user who invokes this function essentially inherits the permissions of the dbo user on any objects accessed within the scope of the function temporarily for the execution of the function:
ALTER FUNCTION [dbo].[AverageBookPrice2](@booktype varchar(12) = '%')
RETURNS money
WITH EXECUTE AS 'dbo'
AS
BEGIN
RETURN ( SELECT avg(price)
FROM titles
WHERE type like @booktype)
END
GO
