October 29, 2009 at 7:28 pm
Guys,
The subject in discussion is not practical in an application development domain for obvious reasons.
From the perspective of DBA/Consultant I can imagine (HARDLY) that sometimes it would be interesting / impressive to show off how to use result set produced by execution of a stored procedure in a SUB-SELECT (you can't use EXECUTE in sub-query at the moment...).
I think that all the story with stored procedures and views on-a-fly - is pure scholastics in the best traditions of Old Testament and Talmud.
Below is a simplified example how to achieve the same results (assuming you have sysadmin credentials, of course). You can substitute system stored procedures with your own.
--Allow distributed queries first
use master
EXEC sp_configure 'show advanced options', 1
GO
reconfigure with override
GO
EXEC sp_configure 'allow updates',1
GO
reconfigure with override
GO
EXEC sp_configure 'Ad Hoc Distributed Queries',1
GO
reconfigure with override
GO
-- Run your "tricks"
SET NOCOUNT ON
SELECT
S.status,
S.dbName,
S.cmd,
O.name,
L.TYPE,
L.mode,
L.status
FROM
(SELECT * FROM OPENROWSET ( 'SQLOLEDB','Server=.\SQL2008;Database=master;Trusted_Connection=yes;','SET FMTONLY OFF EXEC SP_WHO')) S,
(SELECT * FROM OPENROWSET ( 'SQLOLEDB','Server=.\SQL2008;Database=master;Trusted_Connection=yes;','SET FMTONLY OFF EXEC SP_LOCK')) L,
sys.objects O
WHERE
L.OBJID = O.object_id
ANDS.SPID = L.SPID
GO
--Cleanup after yourself
EXEC sp_configure 'Ad Hoc Distributed Queries', 0
GO
reconfigure with override
GO
EXEC sp_configure 'allow updates', 0
GO
EXEC sp_configure 'show advanced options', 0
GO
reconfigure with override
GO
November 12, 2009 at 6:09 pm
use master
go
exec sp_configure 'allow updates',1
go
reconfigure with override
go
exec sp_configure 'Ad Hoc Distributed Queries',1
go
reconfigure with override
>>>>
Configuration option 'allow updates' changed from 0 to 1. Run the RECONFIGURE statement to install.
Msg 15123, Level 16, State 1, Procedure sp_configure, Line 51
The configuration option 'Ad Hoc Distributed Queries' does not exist, or it may be an advanced option.
????????????
SQL Server 2008 is what i'm using..
April 8, 2011 at 2:35 am
Nice article Eli and has certainly generated some discussion.
I too would use OPENROWSET in a derived table, rather than creating the view etc. if I was trying to achieve the same aim with system stored procedures in SQL 2000, but anything that generates four pages of forum posts is good stuff! We only learn from discussions such as this and, if no one has the bottle to put up something to discuss, no one learns!
In 2005+ i would use the DMVs.
Keep on writing.
James
James
MCM [@TheSQLPimp]
April 8, 2011 at 8:24 am
Thanks for the article Eli,
I was just the other day trying to remember how to get the resulset back like that. I'd seen an article a while back... maybe it was yours from 2009?
I think your example threw some people off - They seem obsessed with other ways to access the sp_who and whatever... but that wasn't the point, was it: sometimes we need to get the records from an already-written procedure... that procedure being already in use in other places.. no need to go through a Create Table #xxyyy() to do an Insert / Execute.
SELECT *
FROM OPENROWSET ( 'SQLOLEDB'
, 'SERVER=.;Trusted_Connection=yes'
, ' SET FMTONLY OFF; EXEC [dbname].[dbo].[spName] @paramName = paramValue')
Unfortunately, I have to agree with a few others with regards to opening up the server to Ad Hoc Distributed Queries: no can do - not generally; further, reconfiguring a production server on the fly, then setting it back after the process is done - another no can do.
However, I'll keep this technique in my back pocket: it'll be a good tool for those one-off requests that inevitably come up.
Cheers and best regards form Denver,
Mark
Just a cog in the wheel.
April 8, 2011 at 8:30 am
Just to add to what David McKinney already said - a simple example of how to use the OPENROWSET that makes use of the possibilities offered in the article without wrapping into a stored procedure:
USE master
SELECT *
FROM OPENROWSET('SQLOLEDB','SERVER=.;Trusted_Connection=yes','SET FMTONLY OFF EXEC sp_lock') ORS
LEFT OUTER JOIN (VALUES
('S', 'Shared'),
('IS', 'Intent Shared')
) LockExpl(Mode, ModeText)
ON ORS.Mode = LockExpl.Mode
April 8, 2011 at 5:05 pm
One more minor add-on:
I wrote a similar stored procedure that allows me to pass in a stored procedure name and parameters and it would write the results to a table. I've used it several times to test the results from a new stored procedure against the results from an existing stored proc. All of the data gets put into tables and then you can use checksums to verify that the data in each table is exactly the same. It's a great way to unit test code changes.
Since this happens on dev servers not production, changing the config settings is not a problem.
Paul
April 11, 2011 at 2:33 pm
In my experience, is good to have some way to use SPs instead Table Valued Functions because in a Function you can't use a temporal table to reduce the universe, and this is something very important when you work with a lot of records.
By other side, I see a deep problem of concurrency. If I have several users calling the store procedure, the last win.
I mean, if I have 3 users calling the store procedure to select customers, and this customers should be in the resulting table.
If first need customers with customer name like '%jho%'
the second user need customers with customer name like '%Mik%'
the third user need customers with customer name like '%Mij%'
and three users ask at same time the resulset, the 3 users will get the same results in the table, the data matching with last user where.
Is there some way to avoid it?
April 11, 2011 at 9:37 pm
sandro977 (4/11/2011)
... because in a Function you can't use a temporal table to reduce the universe, and this is something very important...
For that you need: DBCC SHRINKUNIVERSE 😛
sandro977 (4/11/2011)[hrBy other side, I see a deep problem of concurrency. If I have several users calling the store procedure, the last win.
I mean, if I have 3 users calling the store procedure to select customers, and this customers should be in the resulting table.
If first need customers with customer name like '%jho%'
the second user need customers with customer name like '%Mik%'
the third user need customers with customer name like '%Mij%'
and three users ask at same time the resulset, the 3 users will get the same results in the table, the data matching with last user where.
Is there some way to avoid it?
Temporary tables (not temporal) are unique to each session. The problem you describe is what would happen if you used Global Temporary Tables.
Steve.
Viewing 8 posts - 31 through 37 (of 37 total)
You must be logged in to reply to this topic. Login to reply