Debugging stops without messages

Have a task that has 120 tables (components) that I am running in debug mode. Just over half of the components run which takes btrieve db and converts into a sybase db. When it stops running there are a few components that are yellow, the components which completed are green and the rest are still white because they have ran yet. The problem is there is not a message to indicate as to why it stopped. I've broken up the task into two tasks and also tried making two projects. The same situation happens at the same point. Our dbas have checked the database to ensure that's fine and it is. Is there some sort of limitation in how many components can be run in debug mode?

No, but enginethreads may be limiting you here. Read this and see if it helps: http://blogs.conchango.com/jamiethomson/archive/2005/10/02/2227.aspx

-Jamie

|||Thanks for the response. I read the link and tried making a few changes to the enginethreads but no luck. In my original project I had two tasks that were linked and the first one ran without issues and the next task is where it only did the couple of tables. I created a new project and added the package to the new project then deleted the first task. Now that it's a separate project I still have the same issue. Because I copied the original package could there still be some sort of hooks that won't change because of the copy and it will still associate the number of components with the original package? The reason for this question is that I changed the enginethreads to be the max of 60 and when I ran it came back with a message that the required amount of threads in the pipeline were 121 and the max allowed was 64. I was thinking that because the package was copied could the pipeline info still show as 121 instead of the actually component count? Each task originally had about 60 components. Can I delete lines from the xml file that the package creates?|||

I found this log:

04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Input parameters: 4 supplied
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ProcessID = 3368
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ThreadId = 0
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Flags = 0x0
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDumpFlags = 0x0
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, SqlInfoPtr = 0x0100C5D0
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, DumpDir = <NULL>
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExceptionRecordPtr = 0x00000000
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ContextPtr = 0x00000000
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ExtraFile = <NULL>
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, InstanceName = <NULL>
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, ServiceName = <NULL>
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 11 not used
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, Callback type 7 not used
04/04/06 14:46:43, ACTION, SQLDUMPER_UNKNOWN_APP.EXE, MiniDump completed: C:\Program Files\Microsoft SQL Server\90\Shared\ErrorDumps\SQLDmpr0017.mdmp
04/04/06 14:46:43, ACTION, DtsDebugHost.exe, Watson Invoke: No

|||

That looks like it could be a SQL Server issue - that's where SQLDUMPER files come from unless I'm mistaken.

-Jamie

|||

Thanks again Jamie. With my post before the log info just wondered what your opinion was on that? I read the link and tried making a few changes to the enginethreads but no luck. In my original project I had two tasks that were linked and the first one ran without issues and the next task is where it only did the couple of tables. I created a new project and added the package to the new project then deleted the first task. Now that it's a separate project I still have the same issue. Because I copied the original package could there still be some sort of hooks that won't change because of the copy and it will still associate the number of components with the original package? The reason for this question is that I changed the enginethreads to be the max of 60 and when I ran it came back with a message that the required amount of threads in the pipeline were 121 and the max allowed was 64. I was thinking that because the package was copied could the pipeline info still show as 121 instead of the actually component count? Each task originally had about 60 components. Can I delete lines from the xml file that the package creates?

Once again thanks for your responses.

Debugging DataFlow components

I'm trying to do design time debugging of a dataflow component that I developed. I'm clearly doing something wrong, but I can't figure out what so I'm looking for suggestions if anyone has had a similar issue.

The reason I think I doing the steps correctly is that I can debug other components. However, that set seems to be limited to those developed in C#. My component is developed in VB. Shouldn't matter, I wouldn't think.

As a test I tried to debug other VB components from the SQL Server Samples and I have the same problem with them. Last one I tried was ChangeCaseVB. Though I just tried ChangeCaseVS and it didn't stop for me either...

The problem I have is when I drop the controls onto the design surface in the second instance of VS, the first instance of VS, which has the code for the component, does not hit any of the breakpoints, such as ProvideComponentProperties, which I know should be hit, and are hit when I debug a C# component.

To recap, I have an instance of VS open with the code for the component, developed in VB.

I compile the component.

I copy the component to C:\Program Files\Microsoft SQL Server\90\DTS\PipelineComponents

I gacutil the component and then it shows in C:\WINDOWS\assembly

I add the component to the toolbox in my second instance of VS where I am designing the SSIS package which will host the component

I attach my first VS instance to my second VS instance

I drop the component on the designer in the second VS instance.

At this point I expect the first VS instance to hit a breakpoint, it does not.

I have also tried the method of setting the external program and command line arguements in the component's VS for running dtexec.exe directly.

Any suggestions?

Debugging VB or C# is exactly the same, no issues there. I cannot see anything wrong with what you describe, so some general pointers.

Make sure the component has been compiled, GAC'd and copied to the PipelineCOmponenst folder, before you open the second instance of VS that hosts the SSIS project. This will ensure you use the correct version of the assembly, when loaded by the SSIS project, that matches the code instance of VS.

Make sure your code project is set to a Debug build, rather than Release.

Be aware that some properties are design-time, so attach to VS as you have, but others are run-time, in which case, the extrenal program and dtexec is the best way. The design-time hosts (VS) and runtime host (ideally DTEXEC) are different so to debug different methods you need to be attached to the correct host. There is VS run-time host as well, more on that here-

Building, Deploying, and Debugging Custom Objects
(http://msdn2.microsoft.com/en-us/library/b03685bc-5398-4c3f-901a-1219c1098fbe.aspx)

|||

Thank you for the response and "reality check". I have been able to get debugging working now. I'd like to report that I had only one issue, but as I was testing with a variety projects trying to figure this out, they all seeminlgly had different problems, causing myself some extra grief. I still see the same issue from time to time, but overall it's going much better. Thanks for the help.

Debugging and ActiveX Script Task in a DTS Package running on SQL Server 2005

I have a DTS package that I brought over from SQL server 2000 in to SQL Server 2005. I have installed all of the legacy components to run the DTS packages but I need to debug an ActiveX script task. In SQL Server 2000 I could turn on Just-In-Time debugging and use the stop operator (in my vbscript) to break the running script and launch the debugger.

I don't see how to do this in SQL Server 2005 Management Studio. Is it possible to debug a script object in a DTS package running in SQL Server 2005?

Jay Abbott

I have not tried, but another way to stop execution is to use a MsgBox. Whilst it is paused, you could attach the debugger to the DTS process.

I would bin the ActiveX Script, or leave it in DTS. The diagnostic information is absolutely non-existent coming out of the SSIS ActiveX Script Task, and for my money that is unacceptable in a system. Leaving it in DTS is quite easy, and perhaps call the DTS from SSIS to allow you to migrate some functions in your process. Just the fact that no error information is forthcomming in the event of a failure is enough for me to avoid using it entirely.