views:

1574

answers:

4

Is there a way to run a query and then have SQL Server management studio or sqlcmd or something simply display the datatype and size of each column as it was received.

Seems like this information must be present for the transmission of the data to occur between the server and the client. It would be very helpful to me if it could be displayed.

A little background: The reason I ask is because I must interface with countless legacy stored procedures with anywhere from 50 to 5000+ lines of code each. I do not want to have to try and follow the cryptic logic flow in and out of temp tables, into other procedures, into string concatenated eval statement and so on. I wish to maintain no knowledge of the implementation, simply what to expect when they work. Unfortunately following the logic flow seems to be the only way to figure out what exactly is being returned without trying to infer what the actual types of the data string representations om management studio studio or from the native type in .net for example.

To clarify: I am not asking about how to tell the types of a table or something static like that. I'm pretty sure something like sp_help will not help me. I am asking how to tell what the sql server types (ie varchar(25), int...) are of what I have been given. Additionally, changing the implementation of the sprocs is not possible so please consider that in your solutions. I am really hoping there is a command I have missed somewhere. Much appreciation to all.

Update I guess what I am really asking is how to get the schema of the result set when the result set originates from a query using a temp table. I understand this to be impossible but don't find much sense with that conclusion because the data is being transmitted after all. Here is an example of a stored procedure that would cause a problem.

CREATE PROCEDURE [dbo].[IReturnATempTable]
AS

Create table #TempTable 
( 
    MyMysteryColumn char(50)
)

INSERT #TempTable (
    MyMysteryColumn
) VALUES ( 
    'Do you know me?' ) 


select TOP 50 * FROM #TempTable
+1  A: 

What will you do about stored procedures which return different result sets based on their parameters?

In any case, you can configure a SqlDataAdapter.SelectCommand, along with the necessary parameters, then call the FillSchema method. Assuming that the schema can be determined, you'll get a DataTable configured with correct column names and types, and some constraints.

John Saunders
When different results sets are possible, my plan is to be aware of this fact and provide the necessary inputs in order to flush the different results sets out of the proc, each time recording the types returned. I will then set up my client logic to deal with these type accordingly. At this point all I want to know is what is there.
Blake Taylor
I tried the FillSchema and I get "Invalid object name '#tblTempProvider'." So looks like this is going back to the server to get the schema, which unfortunately doesn't help me with the temp tables that are littered through out these procs :( . I was hoping there was some way to pick up the types based on the actual transmission so that this issue could be avoided.
Blake Taylor
Check the SP you got that error on. I bet it references that temp table.
John Saunders
Did you set all the parameters correctly?
John Saunders
See Phillip Kelley's answer below about SET FMTONLY.
John Saunders
It does reference a temp table. I guess that is my real question. I really just want a single reliable way to get the types without looking at the implementation. Temp Tables or not. Why can't SQL server do this? Thanks for the info.
Blake Taylor
How could it possibly do it without actually executing the stored procedure, passing valid parameters?
John Saunders
That is just the thing. I am passing valid parameters and actually executing the stored procedures, but have know way on telling what is coming back when the results are coming from a derived from a TempTable. Hmmm... I wonder if table variables have this same problem.
Blake Taylor
A: 

Could you append another select to your procedure?

If so you might be able to do it by using the *sql_variant_property* function.

Declare @Param Int
Set @Param = 30

Select sql_variant_property(@Param, 'BaseType')
Select sql_variant_property(@Param, 'Precision')
Select sql_variant_property(@Param, 'Scale')

I posted that on this question.

I am asking how to tell what the sql server types (ie varchar(25), int...) are of what I have been given

You could then print out the type, precision (i.e. 25 if its VarChar(25)), and the scale of the parameter.

Hope that helps... :)

Chalkey
I'm pretty sure he wanted information about the resultset from each stored procedure.
John Saunders
+1  A: 

A bit of a long shot, try messing around with SET FMTONLY ON (or off). According to BOL, this "Returns only metadata to the client. Can be used to test the format of the response without actually running the query." I suspect that this will inlcude what you're looking for, as BCP uses this. (I stumbled across this setting when debugging some very oddball BCP problems.)

Philip Kelley
I tried this to but it seemed like the only difference was that no records were returned. I wasn't able to find out any information beyond the column names, count and order.
Blake Taylor
I just remembered a bit more about my oddball BCP problems -- something to do with BCP failing because SET FMTONLY ON interfered with the called procedure calling another procedure, and the parent procedure failed because the "sub"procedure was not being called. If you have nested procedure calls, this may not help you very much. (Did that around our transition from SQL 2000 to 2005, so it probably applies to 2005.)
Philip Kelley
Re: Columns only, yes, that sounds likely -- I'm not sure if BCP wants or needs anything more than that, and for all I know BCP and similar "simple results formats" routines are the only reason SET FMTONLY is present. Might be worth doing some serious online research to see if there's any other "stealth" information returned during such a call...?
Philip Kelley
A: 

If you are not limited to T-SQL, and obviously you don't mind running the SPs (because SET FMTONLY ON isn't fully reliable), you definitely CAN call the SPs from, say C#, using a SqlDataReader. Then inspect the SqlDataReader to get the columns and the data types. You might also have multiple result sets, you you can also go to the next result set easily from this environment.

Cade Roux