Warning #1: Couldn't resolve default property on Add More details
You can ignore this warning.
The add method of the Connections collection takes as input a Connection object. The DTS package uses a Connection2 object. Connection2 is derived from Connection so in theory it should be fine to add it.
GoPackage.Connections.Add(oConnection)
Upgrade notes
Upgrade Note #1: Object oConnection may not be destroyed
until it is garbarge collected.
More details
Remember that one of the advantages of the .NET framework
is the built in garbage collection. Because of this the
following statement is obsolete.
oConnection = Nothing
Change:
Public Sub Main()
oConnection = goPackage.Connections.New("DTSFlatFile")
goPackage.Connections.Add(oConnection)
oConnection = Nothing
:
oConnection = goPackage.Connections.New("DTSFlatFile")
To:
Public Sub Main()
oConnection = goPackage.Connections.New("DTSFlatFile")
goPackage.Connections.Add(oConnection)
:
oConnection = oConnection2 = goPackage.Connections.New
("DTSFlatFile")
In the Visual Basic 6.0 environment the above statement would immediately destroy oConnection. In the .NET framework it only marks it for garbage collection. The proper fix is to call the Dispose() method on the object. Unfortunately this doesn't exist.
Also, if you step through the code you see that the Connections collection keeps references to the oConnection object instead of making a copy of it. Therefore, in the .NET framework if this old object is returned on the next call to New(), and then you modify this object you'll be corrupting data in the stored Connections collection.
What should you do? In most cases you would want to worry about your data being overwritten. However, in this particular case the package also has a reference to the connection, so even setting it to Nothing in the Main() procedure will have no effect. The fix is to remove the call to oConnection = Nothing. The next call to New() will in fact return a new connection object.
For free conversions:
Most of the upgrade issues do get resolved by the converter.
We'll review what happened during the conversion process
because its an excellent illustration of the differences
between Visual Studio 6.0 and Visual Studio .NET
Conversion #1 remove all the Set's for object assignment
This:
Set goPackage =
goPackageOld
was changed to:
goPackage = goPackageOld
In Visual Basic 6.0 the Set keyword distinguishes an assignment between the default properties of two objects from assigning the whole object. Visual Basic .NET doesn't support default properties. Therefore, if the object is referenced on the left and right side of the assignment statement, the whole object will be copied, and the Set keyword can be removed.
Conversion #2
..Value as required when
used on a LHS
This:
oConnection.ConnectionProperties("Data
Source") = "c:\fred.txt"
was changed to:
oConnection.ConnectionProperties("Data
Source").value = "c:\fred.txt"
When a statement unambiguously references a default property the actual default property name is added by the upgrade tool. The code is much more readable and it conforms to the .NET framework rules. In the above case, a ConnectionProperty is actually a reference to an OleProperty object. The default property on this object is the "value" property.
Conversion #3
Parameters to a function must appear
inside ()'s
This:
MsgBox "text
string"
was changed to:
MsgBox ("text string")
The parameters passed into a procedure must be enclosed in ()'s. This is a straight forward upgrade.
Conversion #4
Use of "ByRef" in subroutine
parameter calls.
This:
Public Sub tracePackageError
(oPackage As DTS.Package)
was changed to:
Public Sub tracePackageError
(ByRef oPackage As DTS.Package)
Visual Basic .NET provides better protection of parameters by using the default declaration of ByVal for all parameters. Visual Basic 6.0, by default, assumed all parameters were passed ByRef. Therefore, when the passing mechanism isn't specified, the upgrade tool adds a "ByRef" to keep the parameter passing compatible with the intent of the Visual Basic 6.0 code.
Contents