SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Stored Proc with temp table issue.


Stored Proc with temp table issue.

Author
Message
BlackGarlic
BlackGarlic
SSC Journeyman
SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)

Group: General Forum Members
Points: 85 Visits: 316
@Phil

Actual code has #ID. I made mistake while I was copying the code.

This is the error I am getting:

Exception from HRESULT: 0xC0202009
Error at Data Flow Task [OLE DB Source [18]]: 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 11.0"
Hresult: 0x80004005 Description: "Syntax error, permission violation, or other nonspecific error".

@KoldCoffee

Yes. I am in process of rewriting report query logic to avoid temp table. But I would still like know/learn how to utilize this kind of store proc because we have lot of report written with temp table...

Thanks!
KoldCoffee
KoldCoffee
SSCommitted
SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)SSCommitted (1.5K reputation)

Group: General Forum Members
Points: 1521 Visits: 1905
Before you eliminate the #temp table, take a look at this link and see if it's ideas help solve the #temp table issue.
http://www.sql-server-performance.com/2013/temp-tables-ssis/

As far as the error message, I will tell you that SSIS is notorious for giving messages that lead you nowhere. So, they are of use to a marginal extent, as in CLUEs, but often misleading.
Aadhar Joshi
Aadhar Joshi
SSCommitted
SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)SSCommitted (1.7K reputation)

Group: General Forum Members
Points: 1672 Visits: 451
U can try out with ##temp tables that is (global temp table) use this only u can not find with #temp.
Moreover, u can create physical temp table in tempdb. that is same as #temp table (but u need to create and drop it manually)
Tim Mitchell
Tim Mitchell
SSCommitted
SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)SSCommitted (1.8K reputation)

Group: General Forum Members
Points: 1781 Visits: 2988
This is a fairly common issue with SSIS (at least in versions before SSIS 2012 - I haven't yet tested this on 2012). When using a stored proc as a data source, if that sproc uses temp tables at all, chances are you're going to have some issues using it in SSIS. To make a long story short, SSIS will try to validate the upstream data prior to execution, and if the temp table doesn't yet exist, that validation will often fail.

There are a few workarounds to this, none of which are very pretty. The easiest solution is usually to replace the temp table with a physical staging table (one that is persisted in the database), and just trunc/reload this staging table in the sproc.

If you can't change the sproc, you might consider executing the sproc in an Execute SQL Task and load those results into a staging table directly by doing an INSERT INTO <staging table> EXEC <sproc name>.

Hope this helps...



Tim Mitchell, Microsoft Data Platform MVP
Data Warehouse and ETL Consultant
TimMitchell.net | @Tim_Mitchell | Tyleris.com
ETL Best Practices


BlackGarlic
BlackGarlic
SSC Journeyman
SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)SSC Journeyman (85 reputation)

Group: General Forum Members
Points: 85 Visits: 316
I got this problem finally resolved. So the trick was in the beginning of the stored proc, I just had to declare all column values like following:

if 1=2
begin
select

CAST(NULL AS nvarchar(60)) Account,
CAST(NULL AS datetime) OrderDate,


What a pain!

Thank you all for your tips and suggestions!
Evil Kraig F
Evil Kraig F
SSCrazy Eights
SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)SSCrazy Eights (8.6K reputation)

Group: General Forum Members
Points: 8561 Visits: 7660
I was about to suggest that then realized you'd found your answer as I read down.

There are two things you always do for any stored procedure that's more complex than a single statement. IE: If you can't use it as an iTVF, make this your default:

SET NOCOUNT ON;
SET FMTONLY OFF;

WHILE 0=1
BEGIN

-- SELECT STATEMENT with CONVERT NULL and column names to set the return metadata.

END

Here's why:

1) You don't want multiple results to return to SSIS, so you turn off recordcount. It doesn't foul things up as much as it used to but it's good practice anyway.

2) FMTONLY: Short version, it doesn't 'high speed' through the proc trying to figure out the metadata, it actually compiles. It avoids missing #tmp errors and the like.

3) SELECT with structure first: This is because procs don't carry metadata for the return set, so SSIS has to go in and make some assumptions. The assumption it makes is that it goes to the first SELECT statement, and grabs that metadata. Even if it's an impossible if tree, that is the only SELECT metadata it will take. By front loading it, you always avoid any confusion from further down in the process.


- Craig Farrell

Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.

For better assistance in answering your questions | Forum Netiquette
For index/tuning help, follow these directions. |Tally Tables

Twitter: @AnyWayDBA
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search