现在准备吧数据库放到云上，直接连用ado连太不安全。打算程序调用webservices来进行数据通讯。
但是修改起来工作量太大 （主要是应用程序的修改），想想都头疼， 有没有什么简便点的办法？
38 个解决方案
#1
我分析了一下代码，发现程序主要是通过调用 connection 对象的 execute 方法 来返回 recordset 对象的
也许可以自己重新开发一个connection 类 来代替 ado connection 对象，通过这个新的 connection 对象 来跟 webservices 进行通讯
发送的命令是SQL语句，返回的结果是xml数据
请问哪位做过这种程序，有没有更好的方法 ， 请给点建议 谢谢
也许可以自己重新开发一个connection 类 来代替 ado connection 对象，通过这个新的 connection 对象 来跟 webservices 进行通讯
发送的命令是SQL语句，返回的结果是xml数据
请问哪位做过这种程序，有没有更好的方法 ， 请给点建议 谢谢
#2
恐怕这是最好的办法了。将返回的xml数据再转存至recordset中。
#3
不同的功能对应不同的接口
不要传SQL语句，而是通过传参数的方式去调用，将结果序列化以后返回，客户端收到结果后反序列化
做好用户的识别（登录接口、token管理、甚至是权限级别）——不知道你的老版系统里有没有这一块
最好能记住客户端所有接口的访问日志（根据安全需求，可以选择登录（成功、失败、错误），调用（成功、失败、错误）中的全部或者一部分进行记录）
不要传SQL语句，而是通过传参数的方式去调用，将结果序列化以后返回，客户端收到结果后反序列化
做好用户的识别（登录接口、token管理、甚至是权限级别）——不知道你的老版系统里有没有这一块
最好能记住客户端所有接口的访问日志（根据安全需求，可以选择登录（成功、失败、错误），调用（成功、失败、错误）中的全部或者一部分进行记录）
#4
性能允许的情况下，也可以对传输内容进行压缩
#5
看来Runnerchin做过这样的项目，请多多指教
还有就是 使用webservices 的效率问题，我试了一下，似乎recordset 序列化 很耗服务资源
不知道在 多用户大数据量的时候 效率怎么样。 我的要求是 能保证 500-1000 人同时访问，能基本流畅
#6
不一定要XML或者JSON之类的，也可以用自己的形式进行转化
500-1000这个说不好，做完以后直接弄台服务器压测下看看
500-1000这个说不好，做完以后直接弄台服务器压测下看看
#7
自己拼接 xml 或者 json 速度肯定会好很多 ， 但是这样一来 开发量可就大了
#8
首先确定你程序所有 操作数据库的地方是同一个，这样只要改一个，就可以了。
如果有很多个Connection，那就疯了。
我是通过IIS，客户端访问ASP页，ASP页中调用VB写的操作数据库的DLL，完成CS通信的。
你可以搜索我在CSDN的博客，上面有介绍。
如果有很多个Connection，那就疯了。
我是通过IIS，客户端访问ASP页，ASP页中调用VB写的操作数据库的DLL，完成CS通信的。
你可以搜索我在CSDN的博客，上面有介绍。
#9
谢谢 vansoft
我说一下我的思路：
1、数据库的访问，使用ASP(或.net)+DLL来实现
ASP 负责 接受和返回数据 DLL 负责 业务逻辑
2、用户程序不用浏览器 ， 使用应用程序
3、数据通讯 采用 xml 或者 json
#10
我试了下 自己写程序拼接字符串 速度快很多
#11
现成的解决方案是有, 比如Citrix, 缺点就是要花钱.
思路无非就是WEB端通过控件远程访问服务器局域网中的应用服务器, 对于用户而言是BS的没错, 实际的程序还是服务器上的CS. web上面传输的只不过是应用软件的界面和用户的操作而已.
你可以认为就是一个web版的远程桌面, 当然, 它只传送指定的应用程序.
所以, 也可以直接使用微软自己的远程桌面来实现这个功能, (当然, 只能通过windows自带的远程桌面工具), 也可以通过设置服务器来指定只传送单一应用.
(以前记得windows服务器版免费支持2用户, 再多也要花钱, 但是网上有破解方法)
新版的windows server我倒是没注意过.
如果有兴趣可以去我的文章看看http://blog.csdn.net/wallescai/article/details/2010877
思路无非就是WEB端通过控件远程访问服务器局域网中的应用服务器, 对于用户而言是BS的没错, 实际的程序还是服务器上的CS. web上面传输的只不过是应用软件的界面和用户的操作而已.
你可以认为就是一个web版的远程桌面, 当然, 它只传送指定的应用程序.
所以, 也可以直接使用微软自己的远程桌面来实现这个功能, (当然, 只能通过windows自带的远程桌面工具), 也可以通过设置服务器来指定只传送单一应用.
(以前记得windows服务器版免费支持2用户, 再多也要花钱, 但是网上有破解方法)
新版的windows server我倒是没注意过.
如果有兴趣可以去我的文章看看http://blog.csdn.net/wallescai/article/details/2010877
#12
最简单呢，就是把WEBSERVISE中的数据先下载下来，然后保存到内存中一个虚拟RECORDSET，这样再用控件加载显示就是和以前一样的代码了，区别就是如果控件是可以更新的格子，那改完之后再读出对应列名，对应的RECORDset当行行的ID或关键字，然后再用WEB传回网页更新服务器上的数据。
#13
发送的命令是SQL语句，返回的结果是xml数据，这也可以的，再把XML解析一下变成虚拟RECORDSET，直接用控件连接这个RECORDSET
#14
你要速度快的话你本地就要做好缓存了，最简单就是本地生成一个MDB或SQL SERVER数据库，这样相对来说就和直连 是一样了，主要是做好数据同步问题
#15
做个VPN服务器，这样就不用动代码了，要用软件的VPN连过去
#16
搞定没有，我qq2776478814,有写过类似的
#17
http://blog.csdn.net/pcwe2002/article/details/52000119
使用这种方式直接两层改三层，代码几乎不用动
使用这种方式直接两层改三层，代码几乎不用动
#18
这组件，神了。但是数据库还是暴露在公网上啊。
#19
又看了一边，服务端有东西的。
#20
服务端和客户端使用http连接，客户端连接数据库通过服务器的地址和配置的连接名称，不直接暴露数据库，
这样的好处有几个，
1. 服务器和客户端之间使用加密传输，也不暴露数据库，
2.外网不稳定的情况，直连会经常断开，这个以http,本身就是断连接，所以不存在这个问题
3.访问速度比直连快太多，可以参考速度对比
4.只改连接串，其它代码无需修改
#21
访问速度比直连快太多，为什么直连这么慢我想不通，以前我做过局域网的软件，本机还可以，局域网稍有慢些，外网是直接感觉登录都要半天，打开一个表显示也要好久。
#22
不过这个楼主是现在用不上这玩意了，
只是我们还这么感兴趣
只是我们还这么感兴趣
#23
把服务器游标改成客户端游标，访问速度会立竿见影。
#24
直连只要把服务器游标改成客户端游标，访问速度会立竿见影，跟他这个速度差不多
#25
可以实际外网测试下，测试真实的有数据的字段， 比如示例中
select id,name,dt,des from test1 des大概二十个汉字，10W, 阿里云1M带宽，直连使用aduseclient, 速度是58秒，
使用satrda连接，只需要10秒。
#26
可能aduseclient是连接和取数据都用的是微软的数据层，中间还有协议还有加密，每次可能只取一条
而用satrda，估计服务端的EXE直接用WINSOCK等发送数据，并且是最精简数据，没考虑安全性等问题，一次发送10条起步，
这样速度就会快了5-10倍。
#27
58秒，10秒2个数据了，如果不用aduseclient,你试下要几秒
#28
这里的速度，一个是连接成功需要多少时间（对于只是用DATAGRID控件来说，连接成功速度快就可以了，后面再翻页时有没有卡还要测试）另外一个如果要把所有数据读出来，又是要多少时间，这2个 比较重要
还有更新1万次要多少毫秒
#29
这个58秒是ado连接成功后,只查询并显示在DataGrid中的速度
#30
直连使用aduseclient, 速度是58秒，使用satrda连接，只需要10秒。
不用aduseclient，速度是几秒呢？
你这3个时间是只是单独连接是吧，还不涉及到翻页之类吧。
怎么会58秒这么慢？
一般是连接SQL SERVER要几秒时间，连接成功了，再打开查询要几秒时间，显示到DATAGRID控件上 。
如果说再翻页到最后一条，看要多少时间。
或者说不用DATAGRID控件。
DIM SZ
DIM TSZ
DIM I
REDIM SZ(RS.RECORDCOUNT-1)
REDIM TSZ(RS.FIELDS.COUNT-1)
WHILE NOT RS.EOF
TSZ(0)=RS(0)
TSZ(1)=RS(1)
****
SZ(I)=TSZ
I=i=1
RS.MOVENEXT
WEND
这种方式是3个时间，连接SQL SERVER+查询成功+取完所有数据，时间是要分开计 算的
#31
Dim start As Long
Dim sql As String
Set DataGrid1.DataSource = Nothing
Set rs = New ADODB.Recordset
start = GetTickCount()
sql = "select id,name,dt,des from test1"
rs.Open sql, adocon, adOpenStatic, adLockOptimistic
Set DataGrid1.DataSource = rs
MsgBox CStr(GetTickCount() - start)
这是查询和计算时间的代码，今天试了下不用aduseclient时间是53秒
#32
使用satrda同样的代码，刚才测试只需要不到8秒。有兴趣可以下载试试。
#33
估计satrda是用WINSOCK连接，只是传输一个SQL命令过去，然后返回第 一条？
每次RS.MOVENEXT时，他再重新请求一次？或者说少量做缓存？
可以试下1，连接数据库用时，2，RS.OPEN用时，3，读取完所有数据到内存变量用时
3种方式(不用aduseclient，用aduseclient，用satrda)，3个时间
DIM SZ
DIM TSZ
DIM I
REDIM SZ(RS.RECORDCOUNT-1)
REDIM TSZ(RS.FIELDS.COUNT-1)
WHILE NOT RS.EOF
TSZ(0)=RS(0)
TSZ(1)=RS(1)
****
SZ(I)=TSZ
I=i=1
RS.MOVENEXT
WEND
#34
显示在datagrid中，不管SATRDA还是直连都是取全部数据并显示出来的时间。
#35
ado控件会不会只下载几条数据？
#36
所有数据都显示在了datagrid中
#37
可以用WINSOCK 来。
#38
vansoft 和 pcwe2002 的回复对我很有启发 谢谢
我的解决方法是这样的：
1、使用 IIS 作为数据访问代理， 使用DLL封装
2、 模拟adodb.connection 对象，开发一个 冒牌的 connection 对象，发送sql和接收recordset对象
3、处于安全考虑 ， 发送的命令（加密），返回的数据 （可选择性加密）
综上所述，程序的改动在可接受范围内。目前运行良好
我的解决方法是这样的：
1、使用 IIS 作为数据访问代理， 使用DLL封装
2、 模拟adodb.connection 对象，开发一个 冒牌的 connection 对象，发送sql和接收recordset对象
3、处于安全考虑 ， 发送的命令（加密），返回的数据 （可选择性加密）
综上所述，程序的改动在可接受范围内。目前运行良好
#1
我分析了一下代码，发现程序主要是通过调用 connection 对象的 execute 方法 来返回 recordset 对象的
也许可以自己重新开发一个connection 类 来代替 ado connection 对象，通过这个新的 connection 对象 来跟 webservices 进行通讯
发送的命令是SQL语句，返回的结果是xml数据
请问哪位做过这种程序，有没有更好的方法 ， 请给点建议 谢谢
也许可以自己重新开发一个connection 类 来代替 ado connection 对象，通过这个新的 connection 对象 来跟 webservices 进行通讯
发送的命令是SQL语句，返回的结果是xml数据
请问哪位做过这种程序，有没有更好的方法 ， 请给点建议 谢谢
#2
恐怕这是最好的办法了。将返回的xml数据再转存至recordset中。
#3
不同的功能对应不同的接口
不要传SQL语句，而是通过传参数的方式去调用，将结果序列化以后返回，客户端收到结果后反序列化
做好用户的识别（登录接口、token管理、甚至是权限级别）——不知道你的老版系统里有没有这一块
最好能记住客户端所有接口的访问日志（根据安全需求，可以选择登录（成功、失败、错误），调用（成功、失败、错误）中的全部或者一部分进行记录）
不要传SQL语句，而是通过传参数的方式去调用，将结果序列化以后返回，客户端收到结果后反序列化
做好用户的识别（登录接口、token管理、甚至是权限级别）——不知道你的老版系统里有没有这一块
最好能记住客户端所有接口的访问日志（根据安全需求，可以选择登录（成功、失败、错误），调用（成功、失败、错误）中的全部或者一部分进行记录）
#4
性能允许的情况下，也可以对传输内容进行压缩
#5
看来Runnerchin做过这样的项目，请多多指教
还有就是 使用webservices 的效率问题，我试了一下，似乎recordset 序列化 很耗服务资源
不知道在 多用户大数据量的时候 效率怎么样。 我的要求是 能保证 500-1000 人同时访问，能基本流畅
#6
不一定要XML或者JSON之类的，也可以用自己的形式进行转化
500-1000这个说不好，做完以后直接弄台服务器压测下看看
500-1000这个说不好，做完以后直接弄台服务器压测下看看
#7
自己拼接 xml 或者 json 速度肯定会好很多 ， 但是这样一来 开发量可就大了
#8
首先确定你程序所有 操作数据库的地方是同一个，这样只要改一个，就可以了。
如果有很多个Connection，那就疯了。
我是通过IIS，客户端访问ASP页，ASP页中调用VB写的操作数据库的DLL，完成CS通信的。
你可以搜索我在CSDN的博客，上面有介绍。
如果有很多个Connection，那就疯了。
我是通过IIS，客户端访问ASP页，ASP页中调用VB写的操作数据库的DLL，完成CS通信的。
你可以搜索我在CSDN的博客，上面有介绍。
#9
谢谢 vansoft
我说一下我的思路：
1、数据库的访问，使用ASP(或.net)+DLL来实现
ASP 负责 接受和返回数据 DLL 负责 业务逻辑
2、用户程序不用浏览器 ， 使用应用程序
3、数据通讯 采用 xml 或者 json
#10
我试了下 自己写程序拼接字符串 速度快很多
#11
现成的解决方案是有, 比如Citrix, 缺点就是要花钱.
思路无非就是WEB端通过控件远程访问服务器局域网中的应用服务器, 对于用户而言是BS的没错, 实际的程序还是服务器上的CS. web上面传输的只不过是应用软件的界面和用户的操作而已.
你可以认为就是一个web版的远程桌面, 当然, 它只传送指定的应用程序.
所以, 也可以直接使用微软自己的远程桌面来实现这个功能, (当然, 只能通过windows自带的远程桌面工具), 也可以通过设置服务器来指定只传送单一应用.
(以前记得windows服务器版免费支持2用户, 再多也要花钱, 但是网上有破解方法)
新版的windows server我倒是没注意过.
如果有兴趣可以去我的文章看看http://blog.csdn.net/wallescai/article/details/2010877
思路无非就是WEB端通过控件远程访问服务器局域网中的应用服务器, 对于用户而言是BS的没错, 实际的程序还是服务器上的CS. web上面传输的只不过是应用软件的界面和用户的操作而已.
你可以认为就是一个web版的远程桌面, 当然, 它只传送指定的应用程序.
所以, 也可以直接使用微软自己的远程桌面来实现这个功能, (当然, 只能通过windows自带的远程桌面工具), 也可以通过设置服务器来指定只传送单一应用.
(以前记得windows服务器版免费支持2用户, 再多也要花钱, 但是网上有破解方法)
新版的windows server我倒是没注意过.
如果有兴趣可以去我的文章看看http://blog.csdn.net/wallescai/article/details/2010877
#12
最简单呢，就是把WEBSERVISE中的数据先下载下来，然后保存到内存中一个虚拟RECORDSET，这样再用控件加载显示就是和以前一样的代码了，区别就是如果控件是可以更新的格子，那改完之后再读出对应列名，对应的RECORDset当行行的ID或关键字，然后再用WEB传回网页更新服务器上的数据。
#13
发送的命令是SQL语句，返回的结果是xml数据，这也可以的，再把XML解析一下变成虚拟RECORDSET，直接用控件连接这个RECORDSET
#14
你要速度快的话你本地就要做好缓存了，最简单就是本地生成一个MDB或SQL SERVER数据库，这样相对来说就和直连 是一样了，主要是做好数据同步问题
#15
做个VPN服务器，这样就不用动代码了，要用软件的VPN连过去
#16
搞定没有，我qq2776478814,有写过类似的
#17
http://blog.csdn.net/pcwe2002/article/details/52000119
使用这种方式直接两层改三层，代码几乎不用动
使用这种方式直接两层改三层，代码几乎不用动
#18
这组件，神了。但是数据库还是暴露在公网上啊。
#19
又看了一边，服务端有东西的。
#20
服务端和客户端使用http连接，客户端连接数据库通过服务器的地址和配置的连接名称，不直接暴露数据库，
这样的好处有几个，
1. 服务器和客户端之间使用加密传输，也不暴露数据库，
2.外网不稳定的情况，直连会经常断开，这个以http,本身就是断连接，所以不存在这个问题
3.访问速度比直连快太多，可以参考速度对比
4.只改连接串，其它代码无需修改
#21
访问速度比直连快太多，为什么直连这么慢我想不通，以前我做过局域网的软件，本机还可以，局域网稍有慢些，外网是直接感觉登录都要半天，打开一个表显示也要好久。
#22
不过这个楼主是现在用不上这玩意了，
只是我们还这么感兴趣
只是我们还这么感兴趣
#23
把服务器游标改成客户端游标，访问速度会立竿见影。
#24
直连只要把服务器游标改成客户端游标，访问速度会立竿见影，跟他这个速度差不多
#25
可以实际外网测试下，测试真实的有数据的字段， 比如示例中
select id,name,dt,des from test1 des大概二十个汉字，10W, 阿里云1M带宽，直连使用aduseclient, 速度是58秒，
使用satrda连接，只需要10秒。
#26
可能aduseclient是连接和取数据都用的是微软的数据层，中间还有协议还有加密，每次可能只取一条
而用satrda，估计服务端的EXE直接用WINSOCK等发送数据，并且是最精简数据，没考虑安全性等问题，一次发送10条起步，
这样速度就会快了5-10倍。
#27
58秒，10秒2个数据了，如果不用aduseclient,你试下要几秒
#28
这里的速度，一个是连接成功需要多少时间（对于只是用DATAGRID控件来说，连接成功速度快就可以了，后面再翻页时有没有卡还要测试）另外一个如果要把所有数据读出来，又是要多少时间，这2个 比较重要
还有更新1万次要多少毫秒
#29
这个58秒是ado连接成功后,只查询并显示在DataGrid中的速度
#30
直连使用aduseclient, 速度是58秒，使用satrda连接，只需要10秒。
不用aduseclient，速度是几秒呢？
你这3个时间是只是单独连接是吧，还不涉及到翻页之类吧。
怎么会58秒这么慢？
一般是连接SQL SERVER要几秒时间，连接成功了，再打开查询要几秒时间，显示到DATAGRID控件上 。
如果说再翻页到最后一条，看要多少时间。
或者说不用DATAGRID控件。
DIM SZ
DIM TSZ
DIM I
REDIM SZ(RS.RECORDCOUNT-1)
REDIM TSZ(RS.FIELDS.COUNT-1)
WHILE NOT RS.EOF
TSZ(0)=RS(0)
TSZ(1)=RS(1)
****
SZ(I)=TSZ
I=i=1
RS.MOVENEXT
WEND
这种方式是3个时间，连接SQL SERVER+查询成功+取完所有数据，时间是要分开计 算的
#31
Dim start As Long
Dim sql As String
Set DataGrid1.DataSource = Nothing
Set rs = New ADODB.Recordset
start = GetTickCount()
sql = "select id,name,dt,des from test1"
rs.Open sql, adocon, adOpenStatic, adLockOptimistic
Set DataGrid1.DataSource = rs
MsgBox CStr(GetTickCount() - start)
这是查询和计算时间的代码，今天试了下不用aduseclient时间是53秒
#32
使用satrda同样的代码，刚才测试只需要不到8秒。有兴趣可以下载试试。
#33
估计satrda是用WINSOCK连接，只是传输一个SQL命令过去，然后返回第 一条？
每次RS.MOVENEXT时，他再重新请求一次？或者说少量做缓存？
可以试下1，连接数据库用时，2，RS.OPEN用时，3，读取完所有数据到内存变量用时
3种方式(不用aduseclient，用aduseclient，用satrda)，3个时间
DIM SZ
DIM TSZ
DIM I
REDIM SZ(RS.RECORDCOUNT-1)
REDIM TSZ(RS.FIELDS.COUNT-1)
WHILE NOT RS.EOF
TSZ(0)=RS(0)
TSZ(1)=RS(1)
****
SZ(I)=TSZ
I=i=1
RS.MOVENEXT
WEND
#34
显示在datagrid中，不管SATRDA还是直连都是取全部数据并显示出来的时间。
#35
ado控件会不会只下载几条数据？
#36
所有数据都显示在了datagrid中
#37
可以用WINSOCK 来。
#38
vansoft 和 pcwe2002 的回复对我很有启发 谢谢
我的解决方法是这样的：
1、使用 IIS 作为数据访问代理， 使用DLL封装
2、 模拟adodb.connection 对象，开发一个 冒牌的 connection 对象，发送sql和接收recordset对象
3、处于安全考虑 ， 发送的命令（加密），返回的数据 （可选择性加密）
综上所述，程序的改动在可接受范围内。目前运行良好
我的解决方法是这样的：
1、使用 IIS 作为数据访问代理， 使用DLL封装
2、 模拟adodb.connection 对象，开发一个 冒牌的 connection 对象，发送sql和接收recordset对象
3、处于安全考虑 ， 发送的命令（加密），返回的数据 （可选择性加密）
综上所述，程序的改动在可接受范围内。目前运行良好