简介面向PowerBuilder开发者的远程数据库连接资料包专门解决动态IP环境下PB客户端无法稳定访问SQL Server的问题。内容涉及ODBC与ADO接口配置、SQL Server远程连接开关、TCP/IP协议及1433端口放通、动态DNS映射等关键技术点并给出连接池和重试机制建议适合需要远程维护数据库的PB应用开发者参考。压缩包共25个文件总体积73KB主体为pbl、pbt、pbw等PB工程文件以及srf窗口对象覆盖ODBC配置、加解密、路径获取等功能另附bat远程连接测试脚本与js/css网页辅助文件目录结构清晰。目前已有610人学习浏览。包内含ping远程测试批处理、动态IP下的注册码处理及加解密源码可帮助读者快速搭建远程连接环境理解IP变化时的配置与排错思路是一份小巧实用的参考资源。1. PB远程连接SQL Server先绕过动态IP这道坎做了十来年PB运维最头疼的一句话不是“系统崩了”而是“分厂那边连不上总部数据库了”。用PB远程连接SQL Server看起来就是把连接串里的IP地址从内网换成公网的事可真放到跨地域、出口IP天天变的宽带上这招基本是玄学——今天能连明天分厂那边换个IP段就全部掉线。而 PB 的传统直连方式OLE DB、ODBC在广域网上稳定性本身就一般再加上动态 IP 这个变量基本就是天天救火。这篇笔记要拆的这份资源核心思路不是去跟IP地址死磕而是用一个“查询网关”把远程连接变成一次HTTP请求PB 客户端不再直连数据库端口而是访问一个固定地址的中间层服务由中间层在服务器内网去访问 SQL Server。这样远程IP怎么变客户端永远只认中间层那一个地址。这套方案适合三类人维护老PB系统、被异地分厂连接问题折腾过的工程师以及准备把C/S架构朝“半B/S”方向改造但不想大动干戈的团队。2. 方案选型为什么直连数据库端口不是好主意2.1 直连模式在动态IP下必然翻车的原因很多老系统现在还是这么干的SQL Server 暴露1433端口路由器上做端口映射PB 客户端里写Server公网IP,端口。这个模式在公司有固定公网IP的时候勉强能跑但一旦落在普通宽带或企业动态专线上每个月IP地址一变所有客户端的连接串都得改一遍。更麻烦的是你没法保证两边的防火墙策略能在IP变动后第一时间同步更新经常是分厂那边报错总部这边还一头雾水。动态IP的核心问题不在于“IP会变”而在于“变了你不知道”。PB 的数据库接口没有自动重连域名的机制连接字符串里的IP是写死的。就算你给这条宽带配了DDNS域名SQL Server 的 TCP/IP 属性里也填不了域名只能填IP。所以直连方案在动态IP面前天生就是残废。2.2 中间层方案选型WebService、TCP中继还是数据库网关既然直连不行市面上能绕开动态IP的思路大致有三类。第一类是 TCP 中继在固定IP的服务器上部署一个端口转发工具客户端连中转服务器的固定端口由它把流量再转到 SQL Server。这个方案能解决IP变动问题但报文要经过两层转发SQL Server 的登录认证和数据传输全都裸奔在公共线路上安全性基本看运气。第二类是数据库网关中间层也就是这份资源采用的思路。中间层服务部署在一台能稳定访问 SQL Server 的机器上通常跟数据库同机房对外暴露的是一个HTTP地址。PB 客户端通过 HTTP 调用中间层接口中间层再去执行 SQL 查询并返回数据。这样数据库端口完全不对公网开放SQL Server 的账号密码也不会下发到客户端安全性和稳定性都高一个级别。第三类是内网映射类工具把SQL Server的端口映射到某个固定域名下。这类工具配置简单但免费版本普遍限制流量而且中间节点故障你没法控制对生产系统来说不稳定因素太多。我一般不推荐在正式环境用这个。2.3 三类方案的适用边界对比方案动态IP适应性数据库端口暴露风险实施成本推荐场景直连端口映射差IP变更即断连高1433直接暴露公网低固定IP且安全要求低的临时场景TCP中继中客户端配置固定中协议裸转中临时应急不适合长期中间层WebService好只认HTTP地址低数据库不对外中高生产环境长期运行推荐中间层方案最大的特点是客户端只认识一个HTTP地址。这个地址可以是域名、可以是固定IP反正它不会随着分厂宽带的动态IP变化。代价是你需要一台能同时访问公网和 SQL Server 的机器公司有云服务器最好没有的话一台办公室固定IP的机器也能跑。3. 查询网关实现中间层搭建与核心参数调节3.1 网关整体结构与SQL映射配置这份资源的中间层是一个 ASP.NET Core Web API 项目结构上分三层控制器接收PB客户端的HTTP请求业务层做参数校验和存储过程白名单过滤数据层只负责跟 SQL Server 交互。为什么不用 PB 自带的 WebService 代理而是用普通 Web API因为 PB 的 WebService 代理生成麻烦而且接口一旦变更两边都得重新生成代理。普通 REST 接口用 JSON 传参PowerBuilder 2019 以后原生支持 JSON 解析两边维护成本最低。网关里最关键的文件是proc_map.json它定义了客户端允许调用的存储过程清单和对应的数据库连接名。这样做有两个好处第一PB 客户端永远不能拼接任意 SQL 语句只能在白名单里选存储过程防止有人拿这个接口当 SqlTools 用第二数据库连接信息可以做到按存储过程分组比如查询走只读账号写入操作走另一个权限稍高的账号。{ connectionString: Server192.168.10.50;DatabaseERP_Pro;User Idgw_reader;Passwordxxx;TrustServerCertificatetrue, timeoutSeconds: 30, maxConcurrentQueries: 20, procedures: [ { name: sp_get_sales_report, dbUser: gw_reader, allowedParams: [startDate, endDate, branchId] }, { name: sp_register_outbound_order, dbUser: gw_writer, allowedParams: [orderJson, operator] } ] }这段配置的意图很明显所有客户端发起的查询请求最终都落到sp_get_sales_report这类存储过程上而不是直接塞一段SELECT过来。allowedParams的作用是过滤参数名比如有人传一个tableName参数进来网关直接拒绝因为白名单里没有它。maxConcurrentQueries是给网关加了个并发闸门防止某个分厂跑大报表时把数据库连接池占满影响总部正常业务。3.2 核心代码查询接口与参数化执行中间层的核心接口就一个接收存储过程名和参数字典然后执行并返回JSON。下面是控制器里最关键的ExecuteQuery方法的精简实现[HttpPost(api/query/execute)] public async TaskIActionResult ExecuteQuery([FromBody] QueryRequest req) { if (!_config.Procedures.TryGetValue(req.ProcName, out var proc)) return BadRequest(new { error procedure_not_allowed, message 存储过程不在白名单中 }); var extraParams req.Params.Keys.Except(proc.AllowedParams).ToList(); if (extraParams.Any()) return BadRequest(new { error invalid_params, message $不允许的参数: {string.Join(,, extraParams)} }); using var conn new SqlConnection(proc.GetConnectionString(_config.ConnectionString)); using var cmd new SqlCommand(proc.Name, conn) { CommandType CommandType.StoredProcedure, CommandTimeout _config.TimeoutSeconds }; foreach (var kv in req.Params) cmd.Parameters.AddWithValue( kv.Key, kv.Value ?? DBNull.Value); var dt new DataTable(); using (var da new SqlDataAdapter(cmd)) da.Fill(dt); var json JsonConvert.SerializeObject(dt, new JsonSerializerSettings { DateFormatString yyyy-MM-dd HH:mm:ss, NullValueHandling NullValueHandling.Ignore }); return Ok(new { data json }); }这段代码解决了三个关键问题。第一是白名单校验proc.AllowedParams把传参范围锁死就算有人知道接口地址也传不进SELECT语句。第二是参数化查询所有输入都用AddWithValue绑定杜绝拼接SQL的注入风险。第三是超时控制CommandTimeout从配置读防止某个烂报表挂起几分钟拖死SQL Server。我一般会建议把DefaultCommandTimeout设成 10 秒报表类查询超过 10 秒就该去优化存储过程了而不是指望靠客户端多等。3.3 部署与运行参数调节要点网关部署在带固定IP的服务器上数据库连接串里的Server192.168.10.50是内网地址公网完全访问不到这台 SQL Server。部署时注意三个参数Kestrel 的监听端口默认5000生产我一般用反向代理把她挂到80或443端口下、timeoutSeconds建议10-30别超过60、maxConcurrentQueries这个要看数据库的连接池上限通常 20 左右就够。连接池参数也很关键。SQL Server 的连接复用是中间层性能的命脉我在部署脚本里加了连接池的常规配置PoolingTrue; Min Pool Size5; Max Pool Size50。Min Pool Size5的意思是服务启动后预建 5 个物理连接避免第一个分厂请求进来时现建连接导致的首包延迟。这个数字调大能减少冷启动延迟但会多占 SQL Server 的许可连接数自己权衡。4. PB客户端接入HTTP调用与DataWindow回填4.1 PB侧HTTP调用封装PB 这边的核心工作是把 HTTP 请求封装成一个通用函数任何窗口需要查数时直接调用。PowerBuilder 2019 R3 以后提供了HttpClient对象但老项目如果还在用 PB 12 之前的版本那就得用WinHTTP或者拼一个OLEObject调 MSXML2.ServerXMLHTTP。这里给一个用内置HttpClient的写法// 通用网关查询函数, 返回JSON字符串 // ls_procName: 存储过程名; lparams: 参数数组; ls_conditions: 参数值数组 global function string gf_query_gateway(string ls_procName, string lparams[], string ls_conditions[]) { JsonObject lj_params JsonObject lj_body lj_params create JsonObject lj_body create JsonObject // 组装参数体, 例如 {startDate:2024-01-01,branchId:1001} lj_body.set(procName, ls_procName) lj_params JsonObject() for i 1 to upperbound(lparams) lj_params.set(lparams[i], ls_conditions[i]) next lj_body.set(params, lj_params) HttpClient lh_client HttpResponse lh_resp lh_client create HttpClient lh_client.setRequestHeader(Content-Type, application/json) lh_resp lh_client.post(http://你的网关地址/api/query/execute, lj_body.toString()) if lh_resp.statusCode 200 then return lh_resp.body else return ERROR| string(lh_resp.statusCode) | lh_resp.body end if }PB 的JsonObject在 2017 版本以后才比较稳定老版本如果 API 对不上可以用字符串拼接的方式构造 JSON 请求体只是要注意转义。返回的lh_resp.body是网关注入的 JSON 字符串里面嵌套了一个data字段真正的数据行都在那里面。调用这个函数时PB 侧所有数据库连接对象都不用创建了自然也就不存在“连接串写死IP”的问题。4.2 返回结果回填DataWindow拿到 JSON 串之后很多人习惯自己写循环解析这其实是绕远路。DataWindow 有一个ImportJson方法可以直接把 JSON 数据灌进 DataWindow 的临时表里前提是列结构能对得上。下面是回填 dw_report 的完整流程// 调用网关查询 string ls_json string ls_procName sp_get_sales_report string lparams[] {startDate, endDate, branchId} string ls_vals[] {2024-01-01, 2024-12-31, 1001} ls_json gf_query_gateway(ls_procName, lparams, ls_vals) if left(ls_json, 5) ERROR| then MessageBox(查询失败, ls_json) return end if // 提取data字段的JSON数组部分 JsonObject lj_resp lj_resp create JsonObject lj_resp.fromstring(ls_json) string ls_data lj_resp.getstring(data) // 导入dw_report dw_report.setredraw(false) dw_report.reset() integer li_rtn dw_report.ImportJson(ls_data) dw_report.setredraw(true) if li_rtn 0 then MessageBox(导入失败, ImportJson返回码: string(li_rtn)) end ifImportJson的返回码是有讲究的。返回0表示成功负数则说明列映射失败比如 DataWindow 里没有对应的列名、列类型不匹配。最常见的问题是日期列SQL Server 的datetime传到 JSON 里默认带T分隔符比如2024-01-01T08:30:00PB 的ImportJson在部分版本里解析不了这种格式。所以我在网关联的DateFormatString里强制改成yyyy-MM-dd HH:mm:ss用空格分隔两边实测都稳定。DataWindow 的列名必须和存储过程返回的列名一致否则ImportJson不会报错但数据大量为空。这个坑我踩过不止一次所以建议在网关返回数据前让存储过程统一用AS别名把列名改成和 DataWindow 一致。5. 避坑记录常见问题与排查顺序5.1 现象HTTP能通但返回数据全是乱码现象用浏览器直接访问网关接口返回的 JSON 中文全变成了????或者乱码。原因多半不是网关代码问题而是中间层服务器上的 SQL Server 和 Web API 的字符集不一致或者 PB 客户端请求头没带对编码。SQL Server 的varchar存的是 GBK但 Web API 输出时按 UTF-8 序列化自然就乱了。解决一律把数据库字段统一成nvarchar连接串里加CharacterSetUTF8如果用的驱动支持Web API 的响应头加一句response.Headers[Content-Type] application/json; charsetutf-8。PB 侧HttpClient拿到响应后按 UTF-8 解析基本能根治。5.2 现象连接池被占满分厂一跑报表总部就卡死现象多个分厂同时执行半天下不来的报表查询总部自己的操作也开始超时。原因网关的maxConcurrentQueries设得太高或者中间层跑在了SqlDataReader流式读取模式上没及时关闭连接。等于是把 SQL Server 的 worker 线程全占了。解决把maxConcurrentQueries从 50 改成 20并且确保每个查询用 DataAdapter 一次性Fill到 DataTable不要在连接未关的情况下慢慢遍历。给网关加个最简单的信号量锁超出并发直接返回“系统繁忙请稍后重试”别让请求堆积在数据库层。5.3 现象分厂换宽带后连不上但奇怪的是总部一切正常现象某分厂反馈客户端报“连接超时”但总部分厂两边的网络都通ping 网关地址也通HTTP 接口手动访问也正常。原因中间层的防火墙或反向代理配置里只允许了总部出口IP访问没给分厂新IP段放行。解决这是典型的运维惯性坑。建议网关入口不要按IP白名单限制如果一定需要白名单那就绑网关所在服务器的安全组而不是反向代理层。动态IP场景下在代理层写死IP白名单等于隔三差五要改配置。5.4 现象PB返回“参数个数不匹配”现象PB 客户端调用gf_query_gateway网关返回“存储过程参数不匹配”。原因PB 的数组是从1开始计数的而lj_params.set在设置空参数时可能跳过了某些元素导致 JSON 参数个数对不上存储过程的声明。解决在 PB 的gf_query_gateway里遇到空参数也要显示设置lj_params.set(lparams[i], )不要continue跳过。存储过程侧把参数设为NULL而不是空字符串SQL 里用ISNULL(param, )做一层兜底。6. 进阶验证技巧一分钟定位链路问题那段血泪经验这套资源里还带了一个自检存储过程和一个配套的 PB 测试窗口专门用来快速判断故障在哪一层。自检过程很简单它不接受任何参数直接返回服务器的当前时间、客户端IP、数据库版本和连接状态create procedure dbo.sp_gateway_ping as begin set nocount on select getdate() as server_time, convert(varchar(15), connectionproperty(client_net_address)) as client_ip, version as db_version, OK as status endPB 侧测试窗口拿到返回值后分别检查三件事server_time是否接近本机时间判断中间层服务器有没有时区或系统时间偏差client_ip是否暴露了真实内网地址确认中间层连接的不是公网某个不可达的库db_version是否能正常返回验证 SQL Server 连接串是否有效。我每次给新分厂部署客户端时都会强制走一遍整个流程先让现场同事打开测试窗口执行sp_gateway_ping能返回OK再看数据查询如果OK都回不来直接判断是网关到数据库这一段的问题而不是让业务人员去瞎猜网络。这个习惯帮我在好几次项目交付现场省下了大半天排查时间。从那以后我每上一个新节点第一件事就是先跑一遍自检再谈别的。希望这份资源里的思路和脚本也能帮你把远程连接从玄学变成例行操作。本文还有配套的精品资源点击获取