T Childers (12/7/2012)
Just in case anyone else has gotten here for the same reason I did which was you're trying to build an SSIS package based on a stored procedure that is selecting the data from a temporary table (Select column1, column2, column3 from #tablename).If you can, it worked better if we used a table variable instead:
DECLARE @tablename
(Column1 varchar(10),
column2 varchar(10),
column3 varchar(10)
)
Of course, the problem with that is that the data is put all in memory instead of TempDB, but it did resolve our issue.
Unless your table variable is likely to contain fewer than about 100 rows, I would urge you to reconsider.
Your temp table problem will go away if you publish the meta data at the start of your stored proc (a different technique is needed in 2012 - see later).
Here's how to publish your meta data
-- Publish metadata for SSIS
if 1 = 0
begin
select
cast(null as bit) [Col1],
cast(null as int) [Col2],
etc etc
end
where the column names and data types line up with what your stored proc will return. Job done.
As I mentioned, in SSIS 2012 this technique no longer works. In fact, things have got tidier, because now the meta data is defined in the EXEC statement:
exec usp_proc1 with result sets
(
([Col1] bit,
[Col2] int
);
Now on to my final point. It's a common misconception that table variables are held in memory and do not hit tempdb. You might like to do some further reading on this, as others have done the investigative work far better than I. Try this[/url] for starters.
If you haven't even tried to resolve your issue, please don't expect the hard-working volunteers here to waste their time providing links to answers which you could easily have found yourself.