SQL Server地理字段插入失败的根源排查与正确实践-php教程-PHP中文网

SQL Server地理字段插入失败的根源排查与正确实践

本文解析PHP通过sqlsrv驱动向SQL Server geography 字段写入点数据时出现“纬度必须在-90到90之间”错误的真实原因，揭示常见误判陷阱，并提供可复用的安全写入方案。

本文解析php通过sqlsrv驱动向sql server `geography` 字段写入点数据时出现“纬度必须在-90到90之间”错误的真实原因，揭示常见误判陷阱，并提供可复用的安全写入方案。

在使用 PHP 的 sqlsrv 扩展操作 SQL Server 的 geography 类型字段时，开发者常遇到一个极具迷惑性的报错：

System.FormatException: 24201: Latitude values must be between -90 and 90 degrees

即使传入的纬度值（如 33）明显合法，错误仍持续发生——这往往不是语法或坐标本身的问题，而是参数绑定顺序与地理坐标的语义约定被隐式颠倒所致。

? 关键事实：SQL Server geography::Point() 的参数顺序是 (latitude, longitude, srid)

注意：先纬度（lat），后经度（lon），这与常见的地理 API（如 Google Maps、GeoJSON）或前端习惯（[lng, lat]）相反。而更隐蔽的风险在于：当使用参数化查询时，若 PHP 数组传入顺序与 SQL 中 ? 占位符位置不严格匹配，极易导致 lat 和 lon 被交换。

例如，以下代码存在高危隐患：

$updateqry = "UPDATE tbladdressorg SET location = geography::Point(?, ?, 4326) WHERE addressid = ?";
$updata = array($acct['shippinglongitude'], $acct['shippinglatitude'], $aborg['addressid']);
// ❌ 错误：$updata[0] 是 longitude，但第一个 ? 对应 latitude → 实际执行：Point(long, lat, 4326)
$rslt1 = sqlsrv_query($ssconn, $updateqry, $updata);

此时 SQL Server 将 shippinglongitude（如 116.4）误作纬度传入，超出 [-90, 90] 范围，触发 24201 错误——问题不在数值本身，而在参数错位。

✅ 正确写法：显式对齐语义与占位符

务必确保数组元素顺序严格对应 SQL 中 geography::Point(lat, lon, srid) 的声明顺序：

$updateqry = "UPDATE tbladdressorg SET location = geography::Point(?, ?, 4326) WHERE addressid = ?";
$updata = array(
    $acct['shippinglatitude'],   // ✅ 第一个 ? → latitude
    $acct['shippinglongitude'],  // ✅ 第二个 ? → longitude
    $aborg['addressid']          // ✅ 第三个 ? → addressid
);
$rslt1 = sqlsrv_query($ssconn, $updateqry, $updata);

if ($rslt1 === false) {
    die(print_r(sqlsrv_errors(), true));
}

⚠️ 额外注意事项

SRID 必须显式指定：4326（WGS84）是绝大多数场景的标准值，不可省略或动态拼接（避免 SQL 注入）；
避免字符串拼接坐标：切勿用 "geography::Point({$lat}, {$lng}, 4326)" 方式构造 SQL——既不安全，也丧失参数化优势；

验证输入范围（防御性编程）：

if (!is_numeric($lat) || $lat  90) {
    throw new InvalidArgumentException("Invalid latitude: {$lat}");
}
if (!is_numeric($lng) || $lng  180) {
    throw new InvalidArgumentException("Invalid longitude: {$lng}");
}