Is there any way in Sql Server Management Studio (2008) whereby I can view the data types of each field in the result of a query?
In this case, I am running a stored procedure which returns a result set, and I would like to know the lengths of the nvarchar columns and precision of decimals.
In the past, I have created a view which contains the underlying query in the stored procedure, and then viewed the column list, but the query within the procedure is much too complex to do so in this case.
Any ideas?
Quick and dirty snippet, requires all the fields in the result set are named or aliased;
select * into #T
from
openrowset('SQLNCLI', 'Server=.;Trusted_Connection=yes;', 'exec thedb.dbo.sp_whatever')
exec('use tempdb exec sp_columns #T drop table #T')
Your best bet may be to use OPENROWSET to store the output of the procedure into a table, then examine that table. Something like:
SELECT * INTO YourHoldingTable
FROM OPENROWSET('SQLNCLI', 'Server=YourServerName;Trusted_Connection=yes;', 'EXEC YourDatabase.YourSchema.YourProcedureName')
GO
sp_help 'YourHoldingTable'
GO
DROP TABLE 'YourHoldingTable'
GO
Related
I have a stored procedure looking like this:
SELECT
nTransactionId
,strInstrument
FROM dbo.Deals
I've read that for SQL Server 2012 I can use sp_describe_first_result_set, but is there any alternative for SQL Server 2008?
When I say I want the column names I mean nTransactionId and strInstrument. Even if the query doesn't return any result.
Many thanks!
For that purpose I mostly use :
SET FMTONLY ON;
Returns only metadata to the client. Can be used to test the format of
the response without actually running the query.
Have a look here: Sql Server SET FMTONLY (Transact-SQL)
This is what DataSet designer is using for example in order to get the parameteres of a procedure.
I need to find a T-SQL query in SQL Server 2008 that will tell me how much disk space will be needed for a given dataset in tempdb BEFORE I actually run a select into statement with a given query in order to create a new table.
Example:
select *
into newtable
from bighugetablewithlotsofjoins
So I need to know how much space will be needed by the data returned from bighugetablewithlotsofjoins before I create newtable
run sp_spaceused yourtablename for each table in the join, then calculate the total space required for the worst case scenario (eg. if there are cartesians you'll have to multiply instead of adding)
I'm using mysql and writing some queries using SQLYog's query browser. The sql uses a few variables. Below is an example:
SELECT NOW() #cur_dt;
SELECT 'table' INTO #tbl;
SELECT DATABASE() INTO #db;
SELECT ##hostname INTO #host;
SELECT #host AS `host`, #db AS `database`, #tbl AS `table`, #cur_date AS `dt`;
I'm preparing this sql to be used in SSIS 2005(Sql Server Integration Services) as a source. The issue I'm having is that the variables are coming through as blobs instead of varchars or dates.
I can cast each one which works, but my sql above is just a fraction of what I really need which is a bunch of unions. So in the mean time I'm going to wrap a select around all the unions and cast the fields at that point. I know I could put this in a stored procedure and be done with it but I'm wondering about this exact scenario. My question is if there is a way to specify the variable type when declaring?
Thanks,
GG
PS. If you want to punish a developer make them work with SSIS 2005 and mysql.
How about you select all of your data into a table in the mysql query when you have it accumulated? This will give the data reasonable data types. Then use SSIS to interact with the table, not the variables per se.
Example:
http://sqlfiddle.com/#!2/1b059/1
I am in need of a stored procedure for sales transaction. In a single SP I need to store CustomerID in one table and list of products purchased (multiple rows) in another table.
Can any one give me an best example?
Thanks in advance.
Table-Valued Parameters is a new feature introduced in SQL SERVER 2008. In earlier versions of SQL SERVER it is not possible to pass a table variable in stored procedure as a parameter, but now in SQL SERVER 2008 we can use Table-Valued Parameter to send multiple rows of data to a stored procedure or a function without creating a temporary table or passing so many parameters.
You can read about it here
for more information about using it with ado
check this great article
SQL Server 2008 Table-Valued Parameters and C# Custom Iterators: A Match Made In Heaven!
well in the stored procedure you can use any many insert commands as you want in any table you want, as your question is not clear enough that i write the exact stored procedure you want, I'm writing an example.
use [databasename]
go
create procedure [dbo].[my_stored_procedure](#customerid int) as
begin
insert into [customerstable](customerid) values (#customerid)
insert into [someothertable](somefieldname1, somefieldname2) values(somefield1value, somefield2value)
insert into [someothertable2](somefieldname1, somefieldname2) values(somefield1value, somefield2value)
end
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