
本文揭示php通过sqlsrv驱动向sql server geometry/geography字段写入坐标时出现“latitude must be between -90 and 90”错误的真实原因——并非语法或参数顺序问题,而是隐式数据类型转换与坐标轴顺序混淆导致的底层逻辑误判,并提供可验证的解决方案。
本文揭示php通过sqlsrv驱动向sql server geometry/geography字段写入坐标时出现“latitude must be between -90 and 90”错误的真实原因——并非语法或参数顺序问题,而是隐式数据类型转换与坐标轴顺序混淆导致的底层逻辑误判,并提供可验证的解决方案。
在使用 PHP 的 sqlsrv 扩展操作 SQL Server 地理空间字段(geography 或 geometry)时,开发者常误以为只要复刻 SSMS 中能执行成功的 T-SQL 语句(如 Geography::Point(33, 33, 4326)),就能在 PHP 中直接运行。但实际中却频繁报出看似荒谬的错误:
System.FormatException: 24201: Latitude values must be between -90 and 90 degrees
而 33 显然在合法范围内——这说明问题不在于数值本身,而在于 SQL Server 实际接收到的值被错误解析了。
? 根本原因:坐标参数顺序被反向传递
SQL Server 的 geography::Point() 函数严格要求参数顺序为:
geography::Point( latitude, longitude, SRID )
⚠️ 注意:是 lat, lon,不是 lon, lat!
这与常见 GIS 系统(如 WKT "POINT(long lat)")、Leaflet、GeoJSON 等约定完全相反,极易混淆。
当使用参数化查询时:
$updateqry = "UPDATE tbladdressorg SET location = geography::Point(?, ?, 4326) WHERE addressid = ?"; $updata = array($acct['shippinglongitude'], $acct['shippinglatitude'], $aborg['addressid']); $rslt1 = sqlsrv_query($ssconn, $updateqry, $updata);
若 $acct['shippinglongitude'](经度,如 116.4)被传入第一个 ?,它就会被当作 latitude 解析——而 116.4 超出 [-90, 90] 范围,触发该错误。
✅ 正确做法是显式交换参数顺序,确保 latitude 在前、longitude 在后:
$updateqry = "UPDATE tbladdressorg SET location = geography::Point(?, ?, 4326) WHERE addressid = ?";
// 注意:第1个? = latitude,第2个? = longitude
$updata = array(
$acct['shippinglatitude'], // ✅ 纬度(-90 ~ 90)
$acct['shippinglongitude'], // ✅ 经度(-180 ~ 180)
$aborg['addressid']
);
$rslt1 = sqlsrv_query($ssconn, $updateqry, $updata);
if ($rslt1 === false) {
die(print_r(sqlsrv_errors(), true));
}
? 验证技巧:用 sqlsrv_query + sqlsrv_fetch_array 检查实际绑定值
为避免隐式类型转换干扰(例如字符串 '33' 被误判为浮点精度丢失),建议显式指定参数类型:
$updata = array(
array(&$acct['shippinglatitude'], SQLSRV_PARAM_IN, null, SQLSRV_SQLTYPE_FLOAT),
array(&$acct['shippinglongitude'], SQLSRV_PARAM_IN, null, SQLSRV_SQLTYPE_FLOAT),
array(&$aborg['addressid'], SQLSRV_PARAM_IN, null, SQLSRV_SQLTYPE_INT)
);
$rslt1 = sqlsrv_query($ssconn, $updateqry, $updata);
⚠️ 关键注意事项
- 不要依赖字符串拼接构造 WKT(如 'POINT('.$lon.' '.$lat.')'),SQL Server geography::STGeomFromText() 对格式极其敏感,且需额外调用 .STSRID = 4326;
- geometry 与 geography 不可混用:geometry::Point() 是平面坐标,无 SRID 概念;geography::Point() 是球面坐标,必须指定有效 SRID(如 4326);
- 空值处理:若经纬度可能为空,请在 PHP 层预校验,避免传入 NULL 或非数字值导致 SQL 异常;
- 连接配置:确保 SQL Server 实例已启用 clr enabled = 1(geography 类型依赖 CLR),可通过 sp_configure 'show advanced options', 1; RECONFIGURE; sp_configure 'clr enabled', 1; RECONFIGURE; 启用。
✅ 总结
该错误表象是纬度越界,实则是参数顺序错位引发的语义误读。解决路径非常明确:
- 严格遵循 geography::Point(lat, lon, srid) 的参数契约;
- 在 PHP 数组中按 lat → lon → id 顺序组织参数;
- 使用 SQLSRV_SQLTYPE_FLOAT 显式声明数值类型,规避隐式转换风险;
- 通过 sqlsrv_errors() 捕获并打印完整错误链,而非仅依赖消息片段。
只要厘清 SQL Server 地理类型的设计约定,此类问题即可快速定位、彻底规避。










