C#/.Net 4.6.1查询SQL报错：Int32转Int64无效

我之前做跨库关联查询时也踩过一模一样的坑，结合你的情况，给你几个针对性的排查方向，大概率能定位到问题：

• 先确认查询结果的实际字段类型：
  别只看数据库表结构，把你执行的SQL语句单独拿到SSMS里跑，然后右键结果集→「查看元数据」，检查personId（以及其他Id字段）的实际返回类型是不是bigint。有时候跨库JOIN时，数据库引擎会做隐式类型转换（比如某个关联字段的类型在两个库中不一致？或者你用了CAST/CONVERT不小心转成了int），哪怕表结构是bigint，查询结果可能被转成int，这时候映射到long就会报错。

• 检查实体类的映射细节：

  • 如果用EF：看看实体类的personId属性有没有加错注解，比如不小心写了[Column(TypeName = "int")]；或者Fluent API里有没有错误指定类型。另外还要检查导航属性里的关联Id，比如如果Person类关联了Order，Order类里的PersonId是不是写成int了？
  • 如果用Dapper：确认属性名和数据库字段名是否完全匹配（虽然默认大小写不敏感，但有时候下划线命名转驼峰可能出问题），或者有没有手动指定错误的类型映射。

• 排查跨库兼容性问题：
  同服务器的两个数据库，兼容性级别可能不一样（比如一个是SQL Server 2008，一个是2016），这可能导致引擎对bigint的处理出现差异。你可以执行这条SQL检查：

  SELECT name, compatibility_level FROM sys.databases WHERE name IN ('库名1','库名2')
  

  尽量把两个库的兼容性级别调整一致，避免这类隐性问题。

• 检查是否用到视图/计算列：
  如果你的查询里包含视图或者计算列，一定要确认这些对象里有没有把bigint类型的Id转成int的操作，比如视图里写了SELECT CAST(personId AS INT) AS personId，这种情况表结构是对的，但查询结果已经是int了，自然会报错。

• 用调试工具抓真实返回数据：
  可以临时把查询结果先转成DataTable或者dynamic，看看实际类型：

  // 以Dapper为例
  var result = connection.Query("你的跨库SQL语句");
  var firstItem = result.First();
  Console.WriteLine(firstItem.personId.GetType()); // 看输出是Int32还是Int64
  

  这样能直接定位到是查询返回的类型不对，还是映射环节出了问题。

内容的提问来源于stack exchange，提问作者7 Reeds