views:

773

answers:

6

I am using a Temporary table in Stored Procedure in SQL Server. I am trying to use that SP in OLE DB Source Editor.

I can see the data output returned in the Query Builder that comes with Build Query button. But when i Click the Columns tab, I am getting the below error.

Blockquote

- TITLE: Microsoft Visual Studio

Error at Data Flow Task [OLE DB Source [1]]: SSIS Error Code DTS_E_OLEDBERROR. An OLE DB error has occurred. Error code: 0x80004005. An OLE DB record is available. Source: "Microsoft SQL Server Native Client 10.0" Hresult: 0x80004005 Description: "Invalid object name '##Payment'.".

Error at Data Flow Task [OLE DB Source [1]]: Unable to retrieve column information from the data source. Make sure your target table in the database is available.

##

Blockquote

Does that mean I cant use temp tables in SP, if I want it to be consumed by SSIS

+1  A: 

Nope, it's a permissions issue. This should help you:

http://support.microsoft.com/kb/933835

ajdams
+1  A: 

I used

SET FMTONLY OFF at the start of procedure, which will tell not to process rows to the client when it is not being executed as there is no temp table while parsing the SP, hence no column available while parsing.

It got me working finally :)

Jason M
A: 

If the error was raised while you are in BIDS, then ajdams solution will not work as it only applies to errors raised while running the package from the SQL Server Agent.

The primary problem is that SSIS is struggling to resolve the meta data. From its stand-point, the ## tables don't exist since it can't return the meta data for the object during the pre-execution phase. So you have to find a way to either satisfy its requirement that the table already exists. There are a few solutions:

  1. Don't use temporary tables. Instead, create a working database and put all your objects in it. Obviously, this probably don't work if you are trying to get the data on a server where you aren't a dbo like a production server, so you can't rely on this solution.

  2. Use CTE's instead of temporary tables. This works if your source server is 2005/2008. This won't help if the source server is 2000.

  3. Create the ## table in a separate Execute SQL command. Set the connection's RetainSameConnection property to True. Set DelayValidation to true for the data flow. When you setup the data flow, fake it out by temporarily adding a SELECT TOP 0 field = CAST(NULL AS INT) to the top of the stored procedure that has identical meta data to your final output. Remember to remove this from the stored procedure before you run the package. This is also a handy trick for sharing temporary table data between data flows. If you want the rest of the package to use separate connections so that they can run in parallel, then you have to create an additional non-shared connection. This evades the problem since the temporary table already exists at the time the data flow tasks runs.

Option 3 achieves your goal, but it is complicated and has the limitation that you have to separate the create ## command into another stored procedure call. If you have the ability to create stored procedures on the source server, then you probably also have the ability to create other objects like staging tables and this is usually a better solution. It also side-steps possible TempDB contention issues which is a desirable benefit as well.

Good luck and let me know if you need further guidance on how to implement step 3.

Registered User
A: 

You can use table variables instead of temporary tables . it will work

paranjai
yes, that's the option i kept if this one wouldn't have worked out:)
Jason M
but how temp table going to help u any better .It may be the case if u are planning to use temp table indexing
paranjai
A: 

i think you can also check the below link for more details, its a trick i dont know why microsoft guys make it more simple...

http://www.sqllike.com/using-temporary-tables-with-ssis-40.html

sriram
+1  A: 

For all the hassle involved, I think it is probably just not worth it. Create a real table in the db and truncate it before / after your load. If it's for a datawarehouse it isn't going to matter if you have an extra table or two. This gives you the design-time SSIS tools and means you don't have to worry about the intracacies of temp tables.

If you want to keep things separate, then just create your SSIS temp tables in a separate schema. You can use permissions to make this schmema invisible to all other users.

CREATE SCHEMA [ssis_temp]

CREATE TABLE [ssis_temp].[tempTableName]
AndyM