创建具有未知数据类型的包装器

Question

I'm trying to create a wrapper in T-SQL for a procedure where I'm not sure what the data types are. I can run the wrapper without an INSERT INTO statement and I get the data just fine, but I need to have it in a table.

Whenever I use the INSERT INTO I get an error:

Column name or number of supplied values does not match table definition

I've parsed back through my code and can't see where any column names don't match up, so I'm thinking that it has to be a data type. I've looked through the procedure I'm wrapping to see if I can find what the data types are, but some aren't defined there; I've referenced the tables they pull some data from to find the definitions; I've run SQL_VARIANT_PROPERTY on all of the data to see what data type it is (although some of them come up null).

Is there some better way for me to track down exactly where the error is?

Answer 1

I think you can find out your stored procedure result schema, using sp_describe_first_result_set (available from SQL2012) and FMTONLY . Something like this:

EXEC sp_describe_first_result_set
    @tsql = N'SET FMTONLY OFF; EXEC yourProcedure <params are embedded here>'

More details can be found here .

However, if I remember correctly, this works only if your procedure used deterministic schemas (no SELECT INTO #tempTable or similar things).

One trick to find out the schema of your result is to actually materialize the result into ad-hoc created table. However, this is not easy since SELECT INTO does not work with EXEC procedure . One work-around is this:

1) Define a linked-server to the instance itself. Eg loopback

2) Execute your procedure like this (for SQL 2008R2 ):

    SELECT * INTO tempTableToHoldDataAndStructure
    FROM OPENQUERY(' + @LoopBackServerName + ', ''set fmtonly off exec ' + @ProcedureFullName + ' ' + @ParamsStr

where

@LoopBackServerName = 'loopback'
@ProcedureFullName = loopback.database.schema.procedure_name
@ParamsStr = embedded parameters

For SQL2012 I think the execution might fail if RESULT SETS are not provided (ie schema definition of the expected result, which is kind of a chicken-egg problem in this case):

' WITH RESULT SETS (( ' +  @ResultSetStr + '))'');

Answer 2

Okay, I have a solution to my problem. It's tedious, but tedious I can do. Randomly guessing is what drives me crazy. The procedure I'm wrapping dumps 51 columns. I already know I can get it to work without putting anything into a table. So I decided to comment out part of the select statement in the procedure I'm wrapping so it's only selecting 1 column. (First I made a copy of that procedure so I don't screw up the original; then I referenced the copy from my wrapper). Saved both, ran it, and it worked. So far so good. I could have done it line by line, but I'm more of a binary kind of guy, so I went about halfway down--now I'm including about 25 columns in both the select statement and my table--and it's still working. Repeat procedure until it doesn't work any more, then backtrack until it does again. My error was in identifying one of the data types followed by "IDENTITY". I'm not sure what will happen when I leave that out, but at least my wrapper works.