I have a stored procedure (sproc A) which is syntactically correct. So when I hit "run" on its create or alter statement, it is saved into the database.
However, sproc A has a call to another stored procedure (sproc B). It does not provide enough parameters for sproc B, so I don't see how it's a valid stored procedure.
I want to detect any stored procedures in my database which aren't passing enough parameters to their own stored procedures.
Thankyou,
Fidel
Unfortunately, there is no mechanism in SQL Server to test dependencies, parameters etc
You have to search+check, or provide defaults for parameters. You'll only pick it up by testing otherwise.
A good auto complete tool like Red Gate SQL prompt can list parameters + types for you
Note:
It's a long standing problem and there is even a request to MS including this.
SP parameter checking is one of the OPTION STRICT suggestions
Related
When I execute one of my stored procedures manually, I have to populate several variables.
Most of the variables don't change each time it is run; is it possible to pre-populate the "Value" box so that it only needs to be changed when necessary?
I am reluctant to hard code in the script as there was a series of interlinked procedures which I need to keep dynamic
I'm going to go out on a limb here and guess that you're talking about SQL Server, and that you're executing your procedure through SSMS, because of your description of the graphical interface. In the future, please tag your question with the specific database platform that the question pertains to, and try to be responsive to early comments. You'll get answers much, much faster. (If I'm wrong, just undo the tagging I added to your question.)
Although stored procedures can contain variables, what you're talking about here are parameters; values that are passed into the procedure from the calling code or application.
Parameters can be defined with default values in their declarations.
CREATE OR ALTER PROCEDURE dbo.SomeProc (
#SomeBigIntegerValue bigint = 42
)
AS...
When default values exist, the parameter becomes optional for the caller. The procedure can now be called with or without explicit parameters. Either of these will run.
EXECUTE dbo.SomeProc;
EXECUTE dbo.SomeProc
#SomeBigIntegerValue = 37;
In the first instance, the procedure will use the default value, 42. In the second instance, it will use the parameter value, 37.
You'll note that I named the parameter in the call. That's a best practice, generally, to avoid confusion, but it also allows you to send the parameters in any order. If you don't name them, they will be interpreted in the order they're declared, so you run all manner of risks there.
If you choose to execute the procedure through the GUI, the default values won't be pre-populated, but you can see which parameters have defaults and which don't by expanding the Parameters tab under the procedure name in SSMS. I couldn't find an example with defaults, but it'll looks something like this:
If you want the procedure to use the default value, just tick the Pass Null Value check box.
(In case you're wondering, we have a truncate proc so that our ETL service accounts can have scaled back permissions without having to do fully-logged, row-by-row deletions...)
I have a few linked tables between Microsoft Access and SQL Server. I implemented Access to do all the work in the queries for the database but after further review it was just to slow so I decided to run all the queries in SQL Server by creating stored procedures and have Access just executing a stored procedure as a query. The problem is that some of these stored procedures require parameters. Therefore the code in Access looks like this:
Exec getConsumption #Value1 = Product1
#Value 1 is the parameter needed and Product1 is what I want to pass into the parameter
This all seems to work but is there a way to prompt a user for a text box so that whatever they enter will be passed into the parameter rather than having to go hard code it in every time it needs to be changed ?
Is it possible (using only T-SQL no C# code) to write a stored procedure to execute a series of other stored procedures without passing them any parameters?
What I mean is that, for example, when I want to update a row in a table and that table has a lot of columns which are all required, I want to run the first stored procedure to check if the ID exists or not, if yes then I want to call the update stored procedure, pass the ID but (using the window that SQL Server manager shows after executing each stored procedure) get the rest of the values from the user.
When I'm using the EXEC command, I need to pass all the parameters, but is there any other way to call the stored procedure without passing those parameter? (easy to do in C# or VB, I mean just using SQL syntax)
I think you are asking "can you prompt for user input in a sql script?". No not really.
You could actually do it with seriously hack-laden calls to the Windows API. And it would almost certainly have serious security problems.
But just don't do this. Write a program in C#, VB, Access, Powerscript, Python or whatever makes you happy. Use an tool appropriate to the task.
-- ADDED
Just so you know how ugly this would be. Imagine using the Flash component as an ActiveX object and using Flash to collect input from the user -- now you are talking about the kind of hacking it would be. Writing CLR procs, etc. would be just as big of a hack.
You should be cringing right now. But it gets worse, if the TSQL is running on the sql server, it would likely prompt or crash on the the server console instead of running on your workstation. You should definitely be cringing buy now.
If you are coming from Oracle Accept, the equivalent in just not available in TSQL -- nor should it be, and may it never be.
Right after reading your comment now I can understand what you are trying to do. You want to make a call to procedure and then ask End User to pass values for Parameters.
This is a very very badddddddddddddddddddd approach, specially since you have mentioned you will be making changes to database with this SP.
You should get all the values from your End Users before you make a call to your database(execute procedure), Only then make a call to database you Open a transaction and Commit it or RollBack as soon as possible and get out of there. as it will be holding locks on your resources.
Imagine you make a call to database (execute sp) , sp goes ahead and opens a transaction and now wait for End user to pass values, and your end user decides to go away for a cig, this will leave your resources locked and you will have to go in and kill the process yourself in order to let other user to go and use database/rows.
Solution
At application level (C#,VB) get all the values from End users and only when you have all the required information, only then pass these values to sp , execute it and get out of there asap.
You can specify the parameters by prefixing the name of the parameter with the # sign. For example, you can call an SP like this:
EXEC MyProc #Param1='This is a test'
But, if you are asking if you can get away with NOT providing required parameters, the answer is NO. Required is required. You can make them optional by providing a default value in the declaration of the SP. Then you can either not pass the value or call it like this:
EXEC MyProc #Param1=DEFAULT
--OR
EXEC MyProc DEFAULT
Someone here mentioned that We should avoid naming stored procedures in MS SQL server like sp_XXX
Because that taking addition time to SQL server while check does exist system sotred procedure named like that. Because all system stored procs are starting with sp_.
Now I wondering is that a case with Functions in MSSQL, Does naming functions like fn_ take additional time to SQL while looking for system functions ?
No, I don't think so.
Found the following thread:
http://bytes.com/topic/sql-server/answers/78872-udf-starting-fn_
No. To call a system-supplied [User Defined Function], you
need to use ::, so that is what SQL
Server looks for. All system-supplied
UDFs are table functions, as scalar
system functions are not UDFs at all.
Hope this helps
For functions it does not matter, however it is recommended to NOT use a prefix of sp_ for stored procedures as it defines a system stored procedure and may cause an extra lookup in the MASTER database.
As sp_ prefix is reserved for system
stored procedure and any stored
procedure which has sp_ prefix will
cause an extra lookup in MASTER
database. There is another point to
note that if a stored procedure uses
same name, in user database as system
stored procedure in master database,
the stored procedure in user database
will never get executed as SQL Server
will always look first in master
database and will execute that one
rather one in user database.
http://furrukhbaig.wordpress.com/2007/08/22/stored-procedures-factssheet/
http://msdn.microsoft.com/en-us/library/dd172115.aspx
what is the best way of troubleshoot a stored procedure in SQL Server, i mean from where do you start etc..?
Test each SELECT statements (if any) outside of your stored procedure to see whether it returns the expected results;
Make INSERT and UPDATE statements as simple as possible;
Try to test Inserts and Updates outside of your SP so that you can check it gives the expected results;
Use the debugger provided with SSMS Express 2008.
Visual Studio 2008 / 2010 has a debug facility. Simply connect to to your SQL Server instance in 'Server Explorer' and browse to your stored procedure.
Visual Studio 'Test Edition' also can generate Unit Tests around your stored procedures.
Troubleshooting a complex stored proc is far more than just determining if you can get it to run or not and finding the step which won't run. What is most critical is whether it actually returns the corect results or performs the correct actions.
There are two kinds of stored procs that need extensive abilites to troublshoot. First the the proc which creates dynamic SQL. I never create one of these without an input parameter of #debug. When this parameter is set, I have the proc print the SQl statment as it would have run and not run it. Almost everytime, this leads you right away to the problem as you can then see the syntax error in the generated SQL code. You also can run this sql code to see if it is returning the records you expect.
Now with complex procs that have many steps that affect data, I always use an #test input parameter. There are two things I do with the #test parameter, first I make it rollback the actions so that a mistake in development won't mess up the data. Second, I have it display the data before it rollsback to see what the results would have been. (These actually appear in the reverse order in the proc; I just think of them in this order.)
Now I can see what would have gone into the table or been deleted from the tables without affecting the data permananently. Sometimes, I might start with a select of the data as it was before any actions and then compare it to a select run afterwards.
Finally, I often want to log actions of a complex proc and see exactly what steps happened. I don't want those logs to get rolled back if the proc hits an error, so I set up a table variable for the logging information I want at the start of the proc. After each step (or after an error depending on what I want to log), I insert to this table variable. After the rollback or commit statement, I select the results of the table variable or use those results to log to a permanent logging table. This can be especially nice if you are using dynamic SQL because you can log the SQL that was run and then when something strange fails on prod, you have a record of which statement was run when it failed. You do this in a table variable because those do not go out of scope in a rollback.
In SSMS, you can simply start by opening the proc., and clicking on the check mark button (Parse) next to the Execute button on the menu bar. It reports any errors it finds.
If there are no errors there and you're stored procedure is harmless to run (you're not inserting into tables, just creating a temp table for example), then comment out the CREATE PROCEDURE x (or ALTER PROCEDURE x) and declare all the parameters by copying that part, then define them with valid values. Then run it to see what happens.
Maybe this is simple, but it's a place to start.