Azure Logic App通过本地网关执行SQL Get rows DateTime过滤遇502错误求助

我之前在做Logic App对接本地SQL的时候也踩过这个502的坑，结合自己排查的经验和社区的解决方案，给你拆解下问题根源和可行的解决办法：

• 时间与时区同步异常：本地数据网关服务器和SQL Server的系统时间差过大，或者时区不一致，导致OData的UTC时间在转换解析时出现错误，网关收到无效响应后返回502。
• OData语法兼容性bug：部分旧版本的本地网关或SQL驱动，对带UTC时区的OData日期筛选表达式解析存在问题，无法正确转换为SQL可执行的查询语句。
• 权限或网络链路问题：网关服务账号没有SQL Server的查询权限，或者网络层面（防火墙、企业代理）截断了请求/响应，导致网关无法获取完整的SQL返回结果，进而抛出502错误。
• 字段类型不匹配：如果mdate是SQL的datetime类型（而非datetime2或datetimeoffset），SQL Server对UTC格式的时间处理存在兼容性限制，网关转换查询时出错。

• 同步时间与时区
  • 确保网关服务器和SQL Server的系统时间同步，建议统一设置为UTC时区。可以在网关服务器上执行w32tm /query /status命令检查时间同步状态，在SQL Server中执行SELECT GETUTCDATE(), GETDATE()查看服务器时间。
• 调整OData筛选语法
  • 尝试给时间添加显式类型声明，修改筛选器为：mdate gt datetime'2018-05-07T07:15:12Z'
  • 如果SQL Server使用本地时区，也可以转换为本地时间格式，比如mdate gt '2018-05-07 15:15:12'（根据实际时区换算）
• 升级本地数据网关
  • 旧版本网关存在不少OData解析的已知bug，前往Azure门户下载最新版本地数据网关，覆盖安装后重启网关服务，很多兼容性问题都能解决。
• 排查权限与网络
  • 确认网关服务账号（默认是NT SERVICE\PBIEgwService）拥有目标SQL表的SELECT权限，用telnet <SQL服务器IP> 1433测试网关到SQL的连通性。
  • 检查网关服务器的防火墙是否允许出站到SQL端口的流量，以及企业代理是否拦截了网关的请求或响应。
• 绕过OData，直接使用SQL查询
  • 如果OData筛选始终有问题，最稳妥的规避方式是切换到“Get rows”的Query模式，直接编写SQL语句：

    SELECT * FROM [你的表名] WHERE mdate > '2018-05-07T07:15:12Z'
    

    这样直接让SQL Server执行查询，绕过网关的OData解析环节。

内容的提问来源于stack exchange，提问作者Mark A Johnson