Is there any way to limit the content that is placed into the Progress Tab during execution of a package in debug mode?
My problem is that I have a complex package that puts lots of info in there. This package is called in a loop from another package. Each time the package is called, the new info is added to the existing info in the Progress Tab. Eventually the instance of Dev Studio hangs when it gets too much content in that screen.
The only solution would be if I can limit the output content of that screen or turn it off.
All suggestions appreciated.
Dolllar Dude wrote:
Is there any way to limit the content that is placed into the Progress Tab during execution of a package in debug mode?
My problem is that I have a complex package that puts lots of info in there. This package is called in a loop from another package. Each time the package is called, the new info is added to the existing info in the Progress Tab. Eventually the instance of Dev Studio hangs when it gets too much content in that screen.
The only solution would be if I can limit the output content of that screen or turn it off.
All suggestions appreciated.
My word, that isn't good.My only suggestion is that you run the package without debugging (i.e. CTRL-F5).
Microsoft need to be made aware of this problem. [Microsoft follow-up]
-Jamie
|||Jamie
Thanks for you input. Yes I agree that MS need to know.
In general I like the idea of placing status information into the Progress Tab, however there does need to be some way of turning off or controlling the content.
So far the only other work around is to split the package up into more/smaller packages. It's messy but it works.
I'll check your suggestion to see what sort of content is generated when I run it with CRTL-F5.
Also, FYI, I'm running this on a 4 way Xeon with 4 Gb of RAM.
Thanks for your help.
|||A further thought.
I had hoped that the good folk at MS might be watching this kind of thread ...
|||Hi Dolllar Dude,
could you record your request on the connect site? I think we should look into this.
Thanks,
Bob
|||Dollar Dude,That site is: http://connect.microsoft.com/sqlserver/feedback
Post back here with the link to your submission when done.
Thanks,
Phil|||
I have posted the issue to the Connect site. Here is the link.
Thanks for your comments all.
https://connect.microsoft.com/SQLServer/feedback/ViewFeedback.aspx?FeedbackID=286732
|||Excellent. And detailed repro steps as well. Very rare. Thanks dollar dude.
-Jamie
|||Thanks for reporting the problem and sharing detailed repro steps. We will investigate this issue and update you what the cause is. And if a fix is needed, we will let you know when it will be available.|||Hi MS, can you give me an update on the status of this issue pls? Have you been able to replicate the issue? If it hasn't been tested, can you pls indicate when you think this might make the list.
Thanks
Dolllar.
|||We will get to this sometime in August. Thanks for your patience. We will keep you posted with our findings.|||Thanks Runying
Actually I was pretty surprised that you weren't aware of this issue. Are you aware of the two below? If not I'll log a couple of issues in Connect to show/reproduce.
1 - Convert Data Task incorrectly converts NUMERIC(15) to String or Unicode String - sometimes.
2 - Lookup Task sometimes fails to find the record when using NUMERIC(15) field to lookup.
Dolllar
|||
Dolllar Dude wrote:
Thanks Runying
Actually I was pretty surprised that you weren't aware of this issue. Are you aware of the two below? If not I'll log a couple of issues in Connect to show/reproduce.
1 - Convert Data Task incorrectly converts NUMERIC(15) to String or Unicode String - sometimes.
2 - Lookup Task sometimes fails to find the record when using NUMERIC(15) field to lookup.
Dolllar
It is a known issue that SSIS can choke on NUMERIC fields without a scale. Though I couldn't find a Connect posting for it.
No comments:
Post a Comment