Friday, March 23, 2012

Frustrating Visual Studio crashes when adding Script step

I have two similar packages that are both experiencing this issue.

I need to add a script step to generate an incrementing id for the packages.

Once I add the script step, and then save the package, next time I open the package I get a "Microsoft Visual Studio has encountered a problem and needs to close" error which kills off Visual Studio.

The error signature is:

EventType: clr20r3

P1: devenv.exe

P2: 8.0.50727.762

P3: 45716759

P4: microsoft.sqlserver.txscript

P5: 9.0.242.0

P6: 443f5ab8

P7: 67

P8: d

P9: bbp0yyyc15o2dbouwcacz2m0bodqkotn

If I move the error window to one side, delete the whole Script step, and save the Package, then I can reopen the package again without the error occurring.

Here is the actual code in my script step (in case its of any assistance...)

(I have retyped it from a printout, so it may not be 100%. DOCID is supposed to increment from 1. DREF1 is a system-unique id, that takes up from where the last batch left off, and is a string prefixed by "MP")

Code Snippet

Imports System

Imports System.Data

Imports System.math

Imports Microsoft.SqlServer.Dts.Pipeline.Wrapper

Imports Microsoft.SqlServer.Dta.Runtime.Wrapper

Public Class ScriptMain

Inherits UserComponent

Dim ndx as Int32 = 0

Public Overrides Sub Input0_ProcessInputRow(Byval Row as Input0Buffer)

'

' Add your code here

'

Dim dref as String

ndx = ndx + 1

Row.DOCID = ndx

dref = "MP" + Ctype(ndx + Variables.MPIDOrig, String)

Row.DREF1 = dref

End Sub

Protected Overrides Sub finalize()

Variables.MPID = ndx + Variables.MPIDOrig

MyBase.Finalize()

End Sub

End Class

I have found that when I take out the finalize() function, Visual Studio no longer crashes.

Can anyone suggest a different way to achieve what I am trying to achieve?

|||

Could you to put it into PostExecute()?

Thanks,

Bob

|||

Thanks, yes this was the answer.

It was a bit frustrating, as a relative newbie to SSIS, to find that the Finalize method caused this sort of behaviour, and it wasn't immediately obvious that PostExecute should be used instead.

(By which I mean I actually had to read deeper than jsut fiddling about in the IDE.)

No comments:

Post a Comment