Related
I have checked many threads now and I cant seem to find an answer for this, and I need to be fairly certain / confident that I am correct in assuming this before replying to a client.
so, as the heading states, Does SQL Server validate a stored procedure before running it?
IE: Even if i have an IF statement that will never meet a certain condition, will the code in that IF statement condition be checked and validated before running?
EDIT: Here is a quick example:
DECLARE #ParamSource VARCHAR(2) = 'V3'
IF #ParamSource = 'V1'
BEGIN
--USE LINKED SERVER HERE WHICH THROWS AN ERROR ABOUT CONNECTIONS
END
IF #ParamSource = 'V3'
BEGIN
--DO MY ACTUAL CODE
END
I will never meet that first condition, but for some reason, my stored proc is trying to validate on run time and keeps erroring.
When a stored procedure is created, it is compiled, which means that each object used in a stored procedure is validated. For all existing objects you also need to have access to them. This will create an execution plan for this stored procedure, and as long as the procedure doesn't change, the execution plan should remain valid. If any table object used in the stored procedure does not exist (table only, not linked servers), the execution plan will not be created at this point, but the procedure will be created if no other errors are found.
In your example, you need access to the linked server object to create your stored procedure. After the creation, if you no longer have access to the linked server, your procedure will still run, but will generate an error if it needs to access the linked server IF #ParamSource = 'V1'. However, if it doesn't hit the linked server IF #ParamSource = 'V3', there will be no error.
Basically, it means that the user that creates the procedure needs to have access to the linked server.
While importing the database in mysql, I have got following error:
1418 (HY000) at line 10185: This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its declaration and binary logging is enabled (you *might* want to use the less safe log_bin_trust_function_creators variable)
I don't know which things i need to change. Can any one help me how to resolve this?
There are two ways to fix this:
Execute the following in the MySQL console:
SET GLOBAL log_bin_trust_function_creators = 1;
Add the following to the mysql.ini configuration file:
log_bin_trust_function_creators = 1;
The setting relaxes the checking for non-deterministic functions. Non-deterministic functions are functions that modify data (i.e. have update, insert or delete statement(s)). For more info, see here.
Please note, if binary logging is NOT enabled, this setting does not apply.
Binary Logging of Stored Programs
If binary logging is not enabled, log_bin_trust_function_creators does
not apply.
log_bin_trust_function_creators
This variable applies when binary logging is enabled.
The best approach is a better understanding and use of deterministic declarations for stored functions. These declarations are used by MySQL to optimize the replication and it is a good thing to choose them carefully to have a healthy replication.
DETERMINISTIC
A routine is considered “deterministic” if it always produces the same result for the same input parameters and NOT DETERMINISTIC otherwise.
This is mostly used with string or math processing, but not limited to that.
NOT DETERMINISTIC
Opposite of "DETERMINISTIC".
"If neither DETERMINISTIC nor NOT DETERMINISTIC is given in the routine definition, the default is NOT DETERMINISTIC. To declare that a function is deterministic, you must specify DETERMINISTIC explicitly.".
So it seems that if no statement is made, MySQl will treat the function as "NOT DETERMINISTIC".
This statement from manual is in contradiction with other statement from another area of manual which tells that:
" When you create a stored function, you must declare either that it is deterministic or that it does not modify data. Otherwise, it may be unsafe for data recovery or replication.
By default, for a CREATE FUNCTION statement to be accepted, at least one of DETERMINISTIC, NO SQL, or READS SQL DATA must be specified explicitly. Otherwise an error occurs"
I personally got error in MySQL 5.5 if there is no declaration, so i always put at least one declaration of "DETERMINISTIC", "NOT DETERMINISTIC", "NO SQL" or "READS SQL DATA" regardless other declarations i may have.
READS SQL DATA
This explicitly tells to MySQL that the function will ONLY read data from databases, thus, it does not contain instructions that modify data, but it contains SQL instructions that read data (e.q. SELECT).
MODIFIES SQL DATA
This indicates that the routine contains statements that may write data (for example, it contain UPDATE, INSERT, DELETE or ALTER instructions).
NO SQL
This indicates that the routine contains no SQL statements.
CONTAINS SQL
This indicates that the routine contains SQL instructions, but does not contain statements that read or write data. This is the default if none of these characteristics is given explicitly. Examples of such statements are SELECT NOW(), SELECT 10+#b, SET #x = 1 or DO RELEASE_LOCK('abc'), which execute but neither read nor write data.
Note that there are MySQL functions that are not deterministic safe, such as: NOW(), UUID(), etc, which are likely to produce different results on different machines, so a user function that contains such instructions must be declared as NOT DETERMINISTIC.
Also, a function that reads data from an unreplicated schema is clearly NONDETERMINISTIC.
*
Assessment of the nature of a routine is based on the “honesty” of the
creator: MySQL does not check that a routine declared DETERMINISTIC is
free of statements that produce nondeterministic results. However,
misdeclaring a routine might affect results or affect performance.
Declaring a nondeterministic routine as DETERMINISTIC might lead to
unexpected results by causing the optimizer to make incorrect
execution plan choices. Declaring a deterministic routine as
NONDETERMINISTIC might diminish performance by causing available
optimizations not to be used.
When you create a stored function, you must declare either that it is
deterministic or that it does not modify data. Otherwise, it may be
unsafe for data recovery or replication.
By default, for a CREATE FUNCTION statement to be accepted, at least
one of DETERMINISTIC, NO SQL, or READS SQL DATA must be specified
explicitly. Otherwise an error occurs:
To fix this issue add following lines After Return and Before Begin statement:
READS SQL DATA
DETERMINISTIC
For Example :
CREATE FUNCTION f2()
RETURNS CHAR(36) CHARACTER SET utf8
/*ADD HERE */
READS SQL DATA
DETERMINISTIC
BEGIN
For more detail about this issue please read Here
i use this command on ubuntu:
mysql -u root -p
and enter mysql server error and execute this command in mysql:
SET GLOBAL log_bin_trust_function_creators = 1;
When your function is deterministic, you are safe to declare it to be deterministic.
The location of "DETERMINISTIC" keyword is as follows.
following Donald's comment:
This variable applies when binary logging is enabled.
All I had to do was:
disabled log_bin in my.cnf (#log_bin)
restart mysql
import DB
enable log_bin
restart mysql
That step out that import problem.
(Then I'll review the programmer's code to suggest an improvement)
On Windows 10,
I just solved this issue by doing the following.
Goto my.ini and add these 2 lines under [mysqld]
skip-log-bin
log_bin_trust_function_creators = 1
restart MySQL service
MySQL auto read the configuration from conf.d and mysql.conf.d directory. So create custom.cnf in the directory /etc/mysql/conf.d/ and add the following configs.
[mysqld]
log_bin_trust_function_creators=1
The root user permission is required to create and save the file. Then restart the MySQL server.
Try setting the definer for the function!
So instead of
CREATE FUNCTION get_pet_owner
you will write something akin to
CREATE DEFINER=procadmin#% FUNCTION get_pet_owner
which ought to work if the user prodacmin has rights to create functions/procedures.
In my case the function worked when generated through MySQL Workbench but did not work when run directly as an SQL script. Making the changes above fixed the problem.
When should I use a function rather than a stored procedure in SQL, and vice versa? What is the purpose of each?
Functions are computed values and cannot perform permanent environmental changes to SQL Server (i.e., no INSERT or UPDATE statements allowed).
A function can be used inline in SQL statements if it returns a scalar value or can be joined upon if it returns a result set.
A point worth noting from comments, which summarize the answer. Thanks to #Sean K Anderson:
Functions follow the computer-science definition in that they MUST return a value and cannot alter the data they receive as parameters
(the arguments). Functions are not allowed to change anything, must
have at least one parameter, and they must return a value. Stored
procs do not have to have a parameter, can change database objects,
and do not have to return a value.
Here's a table summarizing the differences:
Stored Procedure
Function
Returns
Zero or more values
A single value (which may be a scalar or a table)
Can use transaction?
Yes
No
Can output to parameters?
Yes
No
Can call each other?
Can call a function
Cannot call a stored procedure
Usable in SELECT, WHERE and HAVING statements?
No
Yes
Supports exception handling (via try/catch)?
Yes
No
Functions and stored procedures serve separate purposes. Although it's not the best analogy, functions can be viewed literally as any other function you'd use in any programming language, but stored procs are more like individual programs or a batch script.
Functions normally have an output and optionally inputs. The output can then be used as the input to another function (a SQL Server built-in such as DATEDIFF, LEN, etc) or as a predicate to a SQL Query - e.g., SELECT a, b, dbo.MyFunction(c) FROM table or SELECT a, b, c FROM table WHERE a = dbo.MyFunc(c).
Stored procs are used to bind SQL queries together in a transaction, and interface with the outside world. Frameworks such as ADO.NET, etc. can't call a function directly, but they can call a stored proc directly.
Functions do have a hidden danger though: they can be misused and cause rather nasty performance issues: consider this query:
SELECT * FROM dbo.MyTable WHERE col1 = dbo.MyFunction(col2)
Where MyFunction is declared as:
CREATE FUNCTION MyFunction (#someValue INTEGER) RETURNS INTEGER
AS
BEGIN
DECLARE #retval INTEGER
SELECT localValue
FROM dbo.localToNationalMapTable
WHERE nationalValue = #someValue
RETURN #retval
END
What happens here is that the function MyFunction is called for every row in the table MyTable. If MyTable has 1000 rows, then that's another 1000 ad-hoc queries against the database. Similarly, if the function is called when specified in the column spec, then the function will be called for each row returned by the SELECT.
So you do need to be careful writing functions. If you do SELECT from a table in a function, you need to ask yourself whether it can be better performed with a JOIN in the parent stored proc or some other SQL construct (such as CASE ... WHEN ... ELSE ... END).
Differences between stored procedures and user-defined functions:
Stored procedures cannot be used in Select statements.
Stored procedures support Deferred Name Resolution.
Stored procedures are generally used for performing business logic.
Stored procedures can return any datatype.
Stored procedures can accept greater numbers of input parameter than user defined functions. Stored procedures can have up to 21,000 input parameters.
Stored procedures can execute Dynamic SQL.
Stored procedures support error handling.
Non-deterministic functions can be used in stored procedures.
User-defined functions can be used in Select statements.
User-defined functions do not support Deferred Name Resolution.
User-defined functions are generally used for computations.
User-defined functions should return a value.
User-defined functions cannot return Images.
User-defined functions accept smaller numbers of input parameters than stored procedures. UDFs can have up to 1,023 input parameters.
Temporary tables cannot be used in user-defined functions.
User-defined functions cannot execute Dynamic SQL.
User-defined functions do not support error handling. RAISEERROR OR ##ERROR are not allowed in UDFs.
Non-deterministic functions cannot be used in UDFs. For example, GETDATE() cannot be used in UDFs.
STORE PROCEDURE
FUNCTION (USER DEFINED FUNCTION)
Procedure can return 0, single or multiple values
Function can return only single value
Procedure can have input, output parameters
Function can have only input parameters
Procedure cannot be called from a function
Functions can be called from procedure
Procedure allows select as well as DML statement in it
Function allows only select statement in it
Exception can be handled by try-catch block in a procedure
Try-catch block cannot be used in a function
We can go for transaction management in procedure
We can not go for transaction management in function
Procedure cannot be utilized in a select statement
Function can be embedded in a select statement
Procedure can affect the state of database means it can perform CRUD operation on database
Function can not affect the state of database means it can not perform CRUD operation on database
Procedure can use temporary tables
Function can not use temporary tables
Procedure can alter the server environment parameters
Function can not alter the environment parameters
Procedure can use when we want instead is to group a possibly- complex set of SQL statements
Function can use when we want to compute and return a value for use in other SQL statements
Write a user-defined function when you want to compute and return a value for use in other SQL statements; write a stored procedure when you want instead is to group a possibly-complex set of SQL statements. These are two pretty different use cases, after all!
Basic Difference
Function must return a value but in Stored Procedure it is optional( Procedure can return zero or n values).
Functions can have only input parameters for it whereas Procedures can have input/output parameters .
Function takes one input parameter it is mandatory but Stored Procedure may take o to n input parameters..
Functions can be called from Procedure whereas Procedures cannot be called from Function.
Advance Difference
Procedure allows SELECT as well as DML(INSERT/UPDATE/DELETE) statement in it whereas Function allows only SELECT statement in it.
Procedures can not be utilized in a SELECT statement whereas Function can be embedded in a SELECT statement.
Stored Procedures cannot be used in the SQL statements anywhere in the WHERE/HAVING/SELECT section whereas Function can be.
Functions that return tables can be treated as another rowset. This can be used in JOINs with other tables.
Inline Function can be though of as views that take parameters and can be used in JOINs and other Rowset operations.
Exception can be handled by try-catch block in a Procedure whereas try-catch block cannot be used in a Function.
We can go for Transaction Management in Procedure whereas we can't go in Function.
source
a User Defined Function is an important tool available to a sql server programmer. You can use it inline in a SQL statement like so
SELECT a, lookupValue(b), c FROM customers
where lookupValue will be an UDF. This kind of functionality is not possible when using a stored procedure. At the same time you cannot do certain things inside a UDF. The basic thing to remember here is that UDF's:
cannot create permanent changes
cannot change data
a stored procedure can do those things.
For me the inline usage of a UDF is the most important usage of a UDF.
Stored Procedures are used as scripts. They run a series of commands for you and you can schedule them to run at certain times. Usually runs multiples DML statements like INSERT, UPDATE, DELETE, etc. or even SELECT.
Functions are used as methods. You pass it something and it returns a result. Should be small and fast - does it on the fly. Usually used in a SELECT statement.
SQL Server functions, like cursors, are meant to be used as your last weapon! They do have performance issues and therefore using a table-valued function should be avoided as much as possible. Talking about performance is talking about a table with more than 1,000,000 records hosted on a server on a middle-class hardware; otherwise you don't need to worry about the performance hit caused by the functions.
Never use a function to return a result-set to an external code (like ADO.Net)
Use views/stored procs combination as much as possible. you can recover from future grow-performance issues using the suggestions DTA (Database Tuning Adviser) would give you (like indexed views and statistics) --sometimes!
for further reference see: http://databases.aspfaq.com/database/should-i-use-a-view-a-stored-procedure-or-a-user-defined-function.html
Stored procedure:
Is like a miniature program in SQL Server.
Can be as simple as a select statement, or as complex as a long
script that adds, deletes, updates, and/or reads data from multiple
tables in a database.
(Can implement loops and cursors, which both allow you to work with
smaller results or row by row operations on data.)
Should be called using EXEC or EXECUTE statement.
Returns table variables, but we can't use OUT parameter.
Supports transactions.
Function:
Can not be used to update, delete, or add records to the database.
Simply returns a single value or a table value.
Can only be used to select records. However, it can be called
very easily from within standard SQL, such as:
SELECT dbo.functionname('Parameter1')
or
SELECT Name, dbo.Functionname('Parameter1') FROM sysObjects
For simple reusable select operations, functions can simplify code.
Just be wary of using JOIN clauses in your functions. If your
function has a JOIN clause and you call it from another select
statement that returns multiple results, that function call will JOIN
those tables together for each line returned in the result set. So
though they can be helpful in simplifying some logic, they can also be a
performance bottleneck if they're not used properly.
Returns the values using OUT parameter.
Does not support transactions.
To decide on when to use what the following points might help-
Stored procedures can't return a table variable where as function can do that.
You can use stored procedures to alter the server environment parameters where as using functions you can't.
cheers
Start with functions that return a single value. The nice thing is you can put frequently used code into a function and return them as a column in a result set.
Then, you might use a function for a parameterized list of cities. dbo.GetCitiesIn("NY") That returns a table that can be used as a join.
It's a way of organizing code. Knowing when something is reusable and when it is a waste of time is something only gained through trial and error and experience.
Also, functions are a good idea in SQL Server. They are faster and can be quite powerful. Inline and direct selects. Careful not to overuse.
Here's a practical reason to prefer functions over stored procedures. If you have a stored procedure that needs the results of another stored procedure, you have to use an insert-exec statement. This means that you have to create a temp table and use an exec statement to insert the results of the stored procedure into the temp table. It's messy. One problem with this is that insert-execs cannot be nested.
If you're stuck with stored procedures that call other stored procedures, you may run into this. If the nested stored procedure simply returns a dataset, it can be replaced with a table-valued function and you'll no longer get this error.
(this is yet another reason we should keep business logic out of the database)
I realize this is a very old question, but I don't see one crucial aspect mentioned in any of the answers: inlining into query plan.
Functions can be...
Scalar:
CREATE FUNCTION ... RETURNS scalar_type AS BEGIN ... END
Multi-statement table-valued:
CREATE FUNCTION ... RETURNS #r TABLE(...) AS BEGIN ... END
Inline table-valued:
CREATE FUNCTION ... RETURNS TABLE AS RETURN SELECT ...
The third kind (inline table-valued) are treated by the query optimizer essentially as (parametrized) views, which means that referencing the function from your query is similar to copy-pasting the function's SQL body (without actually copy-pasting), leading to the following benefits:
The query planner can optimize the inline function's execution just as it would any other sub-query (e.g. eliminate unused columns, push predicates down, pick different JOIN strategies etc.).
Combining several inline function doesn't require materializing the result from the first one before feeding it to the next.
The above can lead to potentially significant performance savings, especially when combining multiple levels of functions.
NOTE: Looks like SQL Server 2019 will introduce some form of scalar function inlining as well.
It is mandatory for Function to return a value while it is not for stored procedure.
Select statements only accepted in UDF while DML statements not required.
Stored procedure accepts any statements as well as DML statements.
UDF only allows inputs and not outputs.
Stored procedure allows for both inputs and outputs.
Catch blocks cannot be used in UDF but can be used in stored procedure.
No transactions allowed in functions in UDF but in stored procedure they are allowed.
Only table variables can be used in UDF and not temporary tables.
Stored procedure allows for both table variables and temporary tables.
UDF does not allow stored procedures to be called from functions while stored procedures allow calling of functions.
UDF is used in join clause while stored procedures cannot be used in join clause.
Stored procedure will always allow for return to zero. UDF, on the contrary, has values that must come - back to a predetermined point.
Functions can be used in a select statement where as procedures cannot.
Stored procedure takes both input and output parameters but Functions takes only input parameters.
Functions cannot return values of type text, ntext, image & timestamps where as procedures can.
Functions can be used as user defined datatypes in create table but procedures cannot.
***Eg:-create table <tablename>(name varchar(10),salary getsal(name))
Here getsal is a user defined function which returns a salary type, when table is created no storage is allotted for salary type, and getsal function is also not executed, But when we are fetching some values from this table, getsal function get’s executed and the return
Type is returned as the result set.
Generally using stored procedures is better for perfomances.
For example in previous versions of SQL Server if you put the function in JOIN condition the cardinality estimate is 1 (before SQL 2012) and 100 (after SQL 2012 and before of SQL 2017) and the engine can generate a bad execution plan.
Also if you put it in WHERE clause the SQL Engine can generate a bad execution plan.
With SQL 2017 Microsoft introduced the feature called interleaved execution in order to produce a more accurate estimate but the stored procedure remains the best solution.
For more details look the following article of Joe Sack
https://techcommunity.microsoft.com/t5/sql-server/introducing-interleaved-execution-for-multi-statement-table/ba-p/385417
In SQL Server, functions and stored procedure are two different types of entities.
Function: In SQL Server database, the functions are used to perform some actions and the action returns a result immediately.
Functions are two types:
System defined
User defined
Stored Procedures: In SQL Server, the stored procedures are stored in server and it can be return zero, single and multiple values.
Stored Procedures are two types:
System Stored Procedures
User Defined Procedures
I am about to write a CREATE FUNCTION with MySQL and I am wondering, if CREATE TEMPORARY TABLE counts toward flag MODIFIES SQL DATA.
Function does not modify any permanent table, just temporary table, which it creates for optimization purpose.
Should I use flag MODIFIES SQL DATA or only READS SQL DATA?
What is a really benefit to use MODIFIES SQL DATA or READS SQL DATA flag anyway?
As of now (MySQL 5.5) these characteristics serve only as an in-code documentation.
From http://dev.mysql.com/doc/refman/5.5/en/create-procedure.html
Several characteristics provide information about the nature of data
use by the routine. In MySQL, these characteristics are advisory only.
The server does not use them to constrain what kinds of statements a
routine will be permitted to execute.
This is in contrast with (NON)DETERMINISTIC clause, which serves as a hint to optimizer whether the results of function can be cached.
My table contains the following fields, Name,Age,Salary,Phone,DOB. Based on a settings table, I have to select only some fields. For example, I say in settings, only Name and Phone is required. How can I do it using stored procedure ?
EDIT :
Which one is good.
Select the required fields from the table.
Select all columns and in ASP.NET page, use .Visibility property to hide or show columns
SQL is a fixed column language: columns can not be added or removed "on the fly"
You would need to use dynamic SQL to build a SELECT statement, or use IF statements to execute different ones. However, you open up caching, security and injection issues.
Personally, I'd ignore columns in the client code and have a simple, single efficient SQL query. The contract or API between SQL Server and the client should be static and predictable. If the settings table is applied in SQL Server, your client doesn't know what columns to expect. If your client does know, then it can ignore them.
After your edit, option 2, kind of.
But the data should be removed before being rendered in the page.
Keep it simple: don't try to optimise anything yet
You would need to have multiple different selects - based on your settings table - in your stored proc to return the different sets of data.
CREATE PROCEDURE dbo.YourProcedure(...)
AS BEGIN
DECLARE #Setting INT -- ?? whatever it is
SELECT #Setting = Choice FROM dbo.YourSettingsTable WHERE ....... ???
IF #Setting = 1
SELECT Name, Phone
FROM dbo.YourDataTable
ELSE
SELECT Name, Age, DOB, Phone, Salary
FROM dbo.YourDataTable
END
Using this approach, however, has its dangers - since the stored proc might return one set of data or quite another, your SQL Server query optimizer might make a very good decision on how to access the data for one setting - but when your setting changes, that execution plan will be totally outdated, thus potentially leading to horrible performance......
On the other hand - it might be easier to determine that setting before calling your stored proc - and then just pass in that setting as a stored proc parameter.
Or even better yet: have separate stored procs for each "scenario" - and then from the caller, call the appropriate stored proc depending on the value of your setting....
Create the sql you want dynamically then execute it with exec.
declare #sql varchar(500)
set #sql = 'select 123'
exec (#sql)
The above code should help you understand what you need to know.
Have a stored procedure for each set of fields you want to select
Allow the list of field names to be passed in as a parameter