Error during upgrade to TFS 2010: System.Data.SqlTypes.SqlNullValueException: Data is Null. This method or property cannot be called on Null values.


Worked a case recently where the customer was upgrading to TFS 2010 (from 08). During the upgrade – the last part specifically when the new project collection was being created – we received an error with these details (taken from the log):

[Info   @01:09:58.712] [2010-06-26 00:55:29Z][Informational] Database name: DefaultCollection
[Info   @01:09:58.712] [2010-06-26 00:55:29Z] Servicing step V3Beta1EventSchemaTransfer passed. (ServicingOperation: UpgradePreTfs2010Databases; Step group: Upgrade.TfsFramework)
[Info   @01:09:58.712] [2010-06-26 00:55:29Z] Executing servicing step Transfer Integration to Version Control. (ServicingOperation: UpgradePreTfs2010Databases; Step group: Upgrade.TfsFramework)
[Info   @01:09:58.712] [2010-06-26 00:55:29Z][Informational] Step Performer: Framework
[Info   @01:09:58.712] [2010-06-26 00:55:29Z][Informational] Step Type:      TransferDatabase
[Info   @01:09:58.712] [2010-06-26 00:55:29Z][Informational] Step Data Text: <TransferDatabaseData sourceCategory="Integration" destinationCategory="VersionControl" resource="BisCreateSchema.sql" />
[Info   @01:09:58.712] [2010-06-26 00:55:29Z][Informational] Retrieving target request context.
[Info   @01:09:58.712] [2010-06-26 00:55:29Z][Informational] Target request context has framework connection string: Data Source=<DS>;Initial Catalog=TfsIntegration;Integrated Security=True.
[Error  @01:09:58.712] [2010-06-26 00:55:29Z][Error] Data is Null. This method or property cannot be called on Null values.
[Info   @01:09:58.712] [2010-06-26 00:55:29Z][Informational] System.Data.SqlTypes.SqlNullValueException: Data is Null. This method or property cannot be called on Null values.

   at System.Data.SqlClient.SqlBuffer.get_String()
   at System.Data.SqlClient.SqlDataReader.GetString(Int32 i)
   at Microsoft.TeamFoundation.Server.Servicing.TFCollection.DatabaseTransfer.DatabaseTransferComponent.DatabaseInfoBinder.Bind(SqlDataReader reader)
   at Microsoft.TeamFoundation.Server.Servicing.TFCollection.DatabaseTransfer.DatabaseTransferComponent.GetDatabaseInfo()
   at Microsoft.TeamFoundation.Server.Servicing.TFCollection.DatabaseTransfer.SameDatabase(DatabaseTransferComponent sourceComponent, DatabaseTransferComponent destinationComponent)
   at Microsoft.TeamFoundation.Server.Servicing.TFCollection.DatabaseTransfer.Execute(ServicingContext servicingContext, String sourceCategory, String destinationCategory)
   at Microsoft.TeamFoundation.Server.Servicing.TFCollection.FrameworkStepPerformer.TransferDatabase(String stepData, ServicingContext servicingContext, Boolean validateOnly)
   at Microsoft.TeamFoundation.Framework.Server.TeamFoundationStepPerformerBase.Microsoft.TeamFoundation.Framework.Server.IStepPerformer.PerformStep(String servicingOperation, String stepType, String stepData, ServicingContext servicingContext)
   at Microsoft.TeamFoundation.Framework.Server.ServicingStepDriver.PerformServicingStep(ServicingStep step, ServicingContext servicingContext, ServicingStepGroup group, ServicingOperation servicingOperation, Boolean validateOnly)
[Info   @01:09:58.712] [2010-06-26 00:55:29Z] Servicing step Transfer Integration to Version Control failed. (ServicingOperation: UpgradePreTfs2010Databases; Step group: Upgrade.TfsFramework)
[Info   @01:09:58.712] [2010-06-26 00:55:29Z][Informational] Clearing dictionary, removing all items.
[Error  @01:09:58.712] The servicing operation failed.

Turns out this was being caused by an empty SERVERNAME value in SQL (SELECT @@SERVERNAME was returning null), and we (TFS) were not prepared for that. We have bugged this of course and will probably either check the SERVERNAME property in a different manner (check SERVERPROPERTY('MachineName') instead, for example) or handle the @@SERVERNAME return value a bit better to resolve it in the future. In the meantime however, if your upgrade log produces an error stack like the one above, check the return value of SELECT @@SERVERNAME on your DT. If it does in fact return a null, you can assign a SERVERNAME by doing this:

exec sp_addserver ‘<new-server-name>, ‘LOCAL’

NOTE: don’t forget the second parameter (‘LOCAL’)!


Comments (0)

Skip to main content