How to deal with System.InvalidOperationException: DataReader.GetFieldType(13)? (again)

Question

After upgrading my ASP.NET webforms application to .NET 4.7.2 (and 4.8) and changing the underlying database server to SQL Server 2017, I started to get this exception:

Exception Details: System.InvalidOperationException: DataReader.GetFieldType(13) returned null.

Underlying datatype of column 13 in the dataset is GEOGRAPHY. I have researched a bit about possible causes and this are things I have tried without success.

1. The machine should have an instance of SQL Server installed. I have it. On my dev computer I have SQL Server 2017 Express and the “production” has SQL Server 2017 for the big boys. So, this is not the culprit.

2. There are suggestions to install package Microsoft.SqlServer.Types. I have installed version 14.0.1016.290. The reference was created, Microsoft.SqlServer.Types.dll was copied in the bin folder. This has not resolved the error.

3. Another suggestion was to put this call into the Global.asax:

   public class Global_asax : System.Web.HttpApplication
   {
       void Application_Start(object sender, EventArgs e)
       {
           ...
           /* For ASP.NET Web Applications, add the following line of code to the Application_Start method in Global.asax.cs: */
           SqlServerTypes.Utilities.LoadNativeAssemblies(Server.MapPath("~/bin"));
       }
   }
   

4. And as a last resort I have added assembly redirect in a web.config. I am not sure if I got publicKeyToken right.

   <assemblyBinding>
       ...
       <dependentAssembly>
           <assemblyIdentity name="Microsoft.SqlServer.Types" 
                             publicKeyToken="89845dcd8080cc91" culture="neutral" />
           <bindingRedirect oldVersion="10.0.0.0" newVersion="14.0.0.0" />
       </dependentAssembly>
   </assemblyBinding>
   

None of the above resolved my problem and this were all the suggestions I could find on various forums and stack exchange. I have looked into the source code of GetFieldType() method found at http://www.dotnetframework.org/default.aspx/4@0/4@0/DEVDIV_TFS/Dev10/Releases/RTMRel/ndp/fx/src/Data/System/Data/SqlClient/SqlDataReader@cs/1305376/SqlDataReader@cs but it offered no clue.

I have thought about there might be some old remnant from previous .Net version that calls incorrect version of this method, but I do not know how to check this. I just think it is a shame Microsoft cannot keep their stuff together. Old version of my app just simply worked.

IMPORTANT: To all of you who think this question was already answered: it was not! It is a persistent problem.

UPDATE - ADDITIONAL INFORMATION My previous configuration on development computer and production server was .NET 4.0 and SQL Server 2008. After upgrading the database to SQL Server 2017 I changed only the connection strings on existing app and it worked. Actually it is still used in production since newer versions od .NET simply do not work.

After that I upgraded my dev machine to .NET 4.8, entity framework to 6.4 and compiled the app. And as result Geography datatype was broken. All steps I have take to remedy this are above. What is wrong here?

Answer 1

The solutions you have tried will fix a different exception, usually variations of this:

System.InvalidOperationException: 'Spatial types and functions are not available for this provider because the assembly 'Microsoft.SqlServer.Types' version 10 or higher could not be found. '

If you are not seeing this error, then we can safely assume that a compatible version of types was found and this is usually enough to say that spatial queries will execute.

Data Type Recommendation I can't say that it is related to this for sure, but for greater success in EF with spatial types you should consider using System.Data.Entity.Spatial.DbGeography in your data classes (model), instead of System.Spatial.Geography

This will still resolve to SQL Geography data type.

To furthur investigate would require more information around the data model and the code that executed to raise the specific exception that OP has experienced. Without this information, I have taken an older commercial ASP.Net, OData v4 API project that was running:

• .Net 4.6.1
• Entity Framework 6.2.0
• Microsoft.Spatial 7.3.1
• Microsoft.SqlServer.Types 14.0.314.76
• System.Spatial 5.8.3

I then upgraded the framework version and references for each project in the solution, there were a few NuGet packages to process so I used this command after changing the framework version of each project to 4.7.2:

Update-Package -Reinstall -IgnoreDependencies

Now the project is as follows:

• .Net 4.7.2
• Entity Framework 6.4.0
• Microsoft.Spatial 7.6.2
• Microsoft.SqlServer.Types 14.0.1016.290
• System.Spatial 5.8.4

The project still works as before, I can query a Paddock from my database and can see the geospatial fields in the result:

• NOTE: in this example the Geospatial fields are defined as follows:

  public DbGeography Perimeter { get; set; }
  public DbGeography GateLocation { get; set; }
  

{
    "@odata.context": "http://localhost:1231/odata/$metadata#Paddocks(EntityID,FarmID,PropertyNumber,VicseedID,VicseedCode,PropertyArea,SketchFile,Isolated,Perimeter,GateLocation,State,SketchData,DefaultInspector)/$entity",
    "EntityID": 8242,
    "FarmID": 6065,
    "PropertyNumber": "1",
    "VicseedID": 3002,
    "Isolated": false,
    "Perimeter": {
        "Geography": {
            "CoordinateSystemId": 4326,
            "WellKnownText": "CURVEPOLYGON (CIRCULARSTRING (146.68923684498316 -38.263219203427454, 146.67772453918761 -38.263219203427454, 146.67772382723493 -38.272258363952844, 146.68923755693584 -38.272258363952844, 146.68923684498316 -38.263219203427454))"
        }
    },
    "GateLocation": {
        "Geography": {
            "CoordinateSystemId": 4326,
            "WellKnownText": "POINT (146.68301582336429 -38.263961881396469)"
        }
    }
}

What to check next?

Run the same SQL query directly in SQL Management Studio, record the results and publish into your question.

Then also publish the code that executes the same query but raises the captured exception.

---

After full regression testing, I can find no new anomolies in the API or the front end and from this I have the personal confidence to reccomend upgrading both to .Net 4.7.2 and Entity Framework 6.4