Is there any built in way, in SQL Server, to override an existing stored procedure for a single transaction?
Say I have a stored procedure
prc_GetValidUsers
#param1 int
...
INSERT INTO *
........prc_GetIdFromString param3
...
...
Is it possible for a single transaction, to redefine what prc_GetIdFromString to be something else? Or is it impossible to do this?
If you are using SQL Server 2005, or later, you could use a SYNONYM to point at the correct code at run time. This would require moving the existing code to an SP with a new name - so the SYNONYM could have the name of the original SP (so that everything that referenced the original SP would not need to be changed). You'd also create another SP that performed the reduced functionality that you want. The SYNONYM could then be pointed at the SP that you want to run.
Related
I am trying to create the script in netezza like what we do in SQL server with variable declaration but I am not able to do it.
Need to create a temp table and then need to pass the parameter to it through a variable.
DECLARE var1 varchar(10);
through error message every time
How to drop a temp table. and how the temp table data is stored and cleared in the memory?
Netezza has its own language for stored procedures - same concept as SQLserver but closer to oracle syntax.
It is however not possible to use the 'variables' construct outside such a stored procedure, which leaves you with a couple of options in your case:
1. do a 'create or replace procedure' with your script embedded, and the execute the sp
2. store intermediate results in temporary tables, and do the 'if-then-else' logic in another scripting language (perl powershell or the like)
We went for option 1 in most cases when moving from SQLserver to Netezza about a year ago...
I query my database from within a .NET application (time recoding). I send the Windows user name to the database and query it depending on this information.
I query a lot of different information with stored procedures, such as holiday, overtime etc. and send them back to the .NET application where I show this data in one form.
Let's say I need the information from SP1, 3 and 4 on Form1:
FORM1:
SP1
SP3
SP4
My problem:
I have a quite complicated table that I need for these stored procedures. At the moment I create this table in every of those stored procedures as temporary tables what is obviously quite time consuming.
What I have tried so far is creating a stored procedure that creates a temp table but this one is not accessable within my other stored procedures.
My question: I am looking for a way to create this table for Form1 once, so I can just access these table in the other stored procedures.
I'm using SQL Server 2014 Express.
If you create the temporary table outside of any stored procedure, it will be accessible within each. Assuming that the actual table definition isn't too complex (but populating it may be), this may be doable.
So you'd execute (effectively):
CREATE TABLE #T (A int not null, B varchar(17) not null)
EXEC PopulateTempTable
EXEC SP1
EXEC SP3
EXEC SP4
All on a single connection. PopulateTempTable may or may not be required, depending on how complex the population of the table is and whether you want that to be performed by your calling code or the database.
You cannot create the temp table inside of a stored procedure since temp tables are automatically dropped when the scope of a stored procedure is exited.
Alternatively, you may want to simulate "session-global" temp tables, as I suggest in this answer1.
The risk with using a global temp table is that it is truly global - all sessions see and interact with the data in the same table. You have to be very careful in such circumstances if it's at all possible that two sessions will attempt to use it at the same time; You generally need some means to filter the data in the table so that each session only works with its own data.
1Probably enhanced these days by also adding a Logon Trigger to clear down the old contents of the table whenever a new connection is established.
You have to create global temp table
CREATE TABLE ##TEMP1
(
Name varchar(50)
)
I would like to know whether my stored procedure will get impacted without specifying Go
Here is the code flow:
Create or replace store_proc1
As
Begin
While loop
{SQL statements repeating itself until source table record count is 0}
End
"Go"
Here I have missed Go at the end of my stored procedure.. Will it impact the performance?
GO is not a SQL statement - it's a delimiter used only in SQL Server Management Studio.
So no, omitting GO will NOT in any way affect your stored procedure's ability to run, nor it performance.
Here's the situation. I'm writing an automated test that walks the list of dependencies for a proc and determines if an acct has rights for all of the dependent objects.
My code looks like this:
exec sp_depends 'the_proc_name'
-- run this query on the results of sp_depends:
select
case
when exists (
select *
from sys.database_permissions dp
where grantee_principal_id=USER_ID('TheAccount')
and major_id=object_id('dbo.theDependentObject')
and minor_id=0
and state_desc = 'GRANT')
then 'true'
else 'false'
end;
It all seems to be working fine, but there's a hiccup when it encounters a function. I have one case where TheAccount doesn't have rights to a function (the query above returns false). However the proc that calls the function in question runs fine when running under TheAccount. So there's either something wrong with my test code or functions have special permission behavior in SQL-Server that I'm not aware of.
Should I change the code to only search for 'DENY' instead of 'GRANT'? Do functions that are called in procs inherit the permissions of the calling proc except when the execute rights are explicitly denied? Does my code suck?
When you are running static SQL from a stored proc, the stored proc runs with the authority of the id that last created/modified the stored proc; not the id of the person running the stored proc.
For example, this is the same ability that allows you to use a stored proc to run an Insert statement without giving the person running the stored proc Insert Authority on the underlying table.
One note - this does not apply when you are using dynamic SQL (with the exec statement). In that case, the person running the stored proc, must have the necessary authority for that SQL statement.
So I'm not sure if your unit tests will provide you what you are looking for since the rights to dependent objects are taken care of, to some extent, by the way SQL Server handles Stored Proc security.
I'd like to put the results of a stored proc into a temp table. It seems that the temp table must be defined beforehand and an INSERT INTO will not work.
Anyone know how to get the schema of the recordset being returned from a select statement?
sp_help only gets info on parameters.
You should be able to insert into a temp table without defining the schema using OPENQUERY:
SELECT * INTO #TempTable
FROM OPENQUERY(ServerName, ‘EXEC DataBaseName.dbo.StoredProcedureName paramvalues1, paramvalues1′)
Where ServerName is the name of your Sql Server instance. See this article for more info
Sometimes you just need to know the schema without creating a table. This command outputs the structure of the resultset without actually executing the stored procedure.
From rachmann on 16 April, 2015 from the Microsoft SQL Server forum article How to get schema of resultset returned by a stored procedure without using OPENQUERY?:
SELECT * FROM sys.dm_exec_describe_first_result_set ('owner.sprocName', NULL, 0) ;
Can you execute the logical content including INSERT INTO in a query window? That should generate a temp table that you can use as a model.
Worst case you build the schema by hand, once, which shouldn't be onerous if you are the one writing the SP.
For the benefit of future documentation, I like to hand-craft DDL in SPs anyway. It helps when debugging to have the schema explicitly at hand.
If you are able, change the stored procedure into a user-defined function.
http://www.scottstonehouse.ca/blog/2007/03/stored-procedures-are-not-parameterized.html