11 个解决方案
#1
更改连接字符串
#2
获取客户端IP，更改连接字符串
#3
Function GetIp() As String
If Not IsDBNull(HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR")) And HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR") <> "" Then
Return HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR")
Else
Return HttpContext.Current.Request.ServerVariables("REMOTE_ADDR")
End If
End Function
If Not IsDBNull(HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR")) And HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR") <> "" Then
Return HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR")
Else
Return HttpContext.Current.Request.ServerVariables("REMOTE_ADDR")
End If
End Function
#4
楼主，你的意思是不是这样：
1、网站运行在服务器A上
2、用户从自己的机器B登陆网站A
3、登录后，网站A的代码要连接安装在客户机B上的数据库
不知道我的猜测对不对。这种设计从架构上来说就注定是失败的。原因如下：
1、直接违反B/S应用的初衷，即简化客户端部署（客户端只需要浏览器即可）。在客户端部署数据库文件甚至数据库系统大大增加了维护成本，以至于可能还不如基于Window Form的C/S或者多层应用便捷。
2、从服务器到客户机的数据库连接很容易因为internet固有的特性而失败。首先如果你是用的是文件型数据库如Access，服务器基本是无法直接访问远程Access文件的。其次，即使客户端使用SQL Server Express这样允许远端连接的DBMS，也很容易受到防火墙或者NAT的限制。举个例子，服务器要想连接没有公网IP的客户机，是非常困难的，往往需要客户端首先驳接VPN。
3、Internet的弱连接特性，使得“服务器访问客户机”的数据访问方式极为不可靠并且低效（想象一下，服务器通过56kbps的拨号连接来连接客户机，并想要读取1MB的数据使用），最终的用户体验可能极为可怕，以至于没人愿意去用它。
如果这是一个基于LAN或者Intranet的应用，可能还好一些，因为你可以控制很多东西，但未来一旦你需要扩大部署，你就会绝望的发现扩展是如此的困难以至于几乎不可能做到。
归根结底，楼主最好能列出这个需求的根本原因，然后分析一下真正可行的方案，而不是一上来就认准要做“服务器连接客户端”。
1、网站运行在服务器A上
2、用户从自己的机器B登陆网站A
3、登录后，网站A的代码要连接安装在客户机B上的数据库
不知道我的猜测对不对。这种设计从架构上来说就注定是失败的。原因如下：
1、直接违反B/S应用的初衷，即简化客户端部署（客户端只需要浏览器即可）。在客户端部署数据库文件甚至数据库系统大大增加了维护成本，以至于可能还不如基于Window Form的C/S或者多层应用便捷。
2、从服务器到客户机的数据库连接很容易因为internet固有的特性而失败。首先如果你是用的是文件型数据库如Access，服务器基本是无法直接访问远程Access文件的。其次，即使客户端使用SQL Server Express这样允许远端连接的DBMS，也很容易受到防火墙或者NAT的限制。举个例子，服务器要想连接没有公网IP的客户机，是非常困难的，往往需要客户端首先驳接VPN。
3、Internet的弱连接特性，使得“服务器访问客户机”的数据访问方式极为不可靠并且低效（想象一下，服务器通过56kbps的拨号连接来连接客户机，并想要读取1MB的数据使用），最终的用户体验可能极为可怕，以至于没人愿意去用它。
如果这是一个基于LAN或者Intranet的应用，可能还好一些，因为你可以控制很多东西，但未来一旦你需要扩大部署，你就会绝望的发现扩展是如此的困难以至于几乎不可能做到。
归根结底，楼主最好能列出这个需求的根本原因，然后分析一下真正可行的方案，而不是一上来就认准要做“服务器连接客户端”。
#5
高人，谢谢，我也有这方面问题可考虑，可是就是有用户的变态要求，远程连接服务器，确实有很多弊端，谢谢你的明确提出，我会在考虑一下，再次感谢，再过一段时间，我在给分
#6
你这种方法，是不是通过Js脚本，获取客户端数据库的有效信息，是通过Js方法获取数据库数据吗？？
#7
我希望你把背后的需求详细写出来，也许我可以帮你考虑一下变通的解决办法。
举个例子，如果连接客户端数据库的原因仅仅是为了上传一些客户离线编辑的数据（很常见，比方说有些账务数据是在库房里用几台没有联网的电脑输入的，然后每天下班时把新数据保存到U盘上，用一台联网的机器上传到服务器上），你可以考虑开放数据上传功能。即将需要处理的数据在客户端先处理好（例如，找出新增或者删除、修改过的记录，产生一个增量变化数据集，用文本文件或者一个Access数据库存放），然后用文件上传功能上传到服务器端。服务器接收到上传的完整数据之后，可以进行在线或者离线的处理。这样要远远优于想办法建立从服务器到浏览器的主动连接。
举个例子，如果连接客户端数据库的原因仅仅是为了上传一些客户离线编辑的数据（很常见，比方说有些账务数据是在库房里用几台没有联网的电脑输入的，然后每天下班时把新数据保存到U盘上，用一台联网的机器上传到服务器上），你可以考虑开放数据上传功能。即将需要处理的数据在客户端先处理好（例如，找出新增或者删除、修改过的记录，产生一个增量变化数据集，用文本文件或者一个Access数据库存放），然后用文件上传功能上传到服务器端。服务器接收到上传的完整数据之后，可以进行在线或者离线的处理。这样要远远优于想办法建立从服务器到浏览器的主动连接。
#8
感谢你的积极帮助，项目暂时还在策划阶段，我们还需要考虑用户需求，并要和用户协商，我们在考虑新的解决方案。再次感谢你的回复
#9
晕，服务器能连接客户器的数据吗？内网还有点可能，外网除非是自己内部人员专用的，不然谁的机上有你要用的数据库呢，就算有受防火墙、网关种种限制你也可能访问不了
#10
你宁可做个上传页面给他把数据库传到服务器，然后再由服务器自动合并数据，远程连接本地数据库稳定性和可操作性太差了
#11
谢谢你的提议，我正在考虑，呵呵
#1
更改连接字符串
#2
获取客户端IP，更改连接字符串
#3
Function GetIp() As String
If Not IsDBNull(HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR")) And HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR") <> "" Then
Return HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR")
Else
Return HttpContext.Current.Request.ServerVariables("REMOTE_ADDR")
End If
End Function
If Not IsDBNull(HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR")) And HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR") <> "" Then
Return HttpContext.Current.Request.ServerVariables("HTTP_X_FORWARDED_FOR")
Else
Return HttpContext.Current.Request.ServerVariables("REMOTE_ADDR")
End If
End Function
#4
楼主，你的意思是不是这样：
1、网站运行在服务器A上
2、用户从自己的机器B登陆网站A
3、登录后，网站A的代码要连接安装在客户机B上的数据库
不知道我的猜测对不对。这种设计从架构上来说就注定是失败的。原因如下：
1、直接违反B/S应用的初衷，即简化客户端部署（客户端只需要浏览器即可）。在客户端部署数据库文件甚至数据库系统大大增加了维护成本，以至于可能还不如基于Window Form的C/S或者多层应用便捷。
2、从服务器到客户机的数据库连接很容易因为internet固有的特性而失败。首先如果你是用的是文件型数据库如Access，服务器基本是无法直接访问远程Access文件的。其次，即使客户端使用SQL Server Express这样允许远端连接的DBMS，也很容易受到防火墙或者NAT的限制。举个例子，服务器要想连接没有公网IP的客户机，是非常困难的，往往需要客户端首先驳接VPN。
3、Internet的弱连接特性，使得“服务器访问客户机”的数据访问方式极为不可靠并且低效（想象一下，服务器通过56kbps的拨号连接来连接客户机，并想要读取1MB的数据使用），最终的用户体验可能极为可怕，以至于没人愿意去用它。
如果这是一个基于LAN或者Intranet的应用，可能还好一些，因为你可以控制很多东西，但未来一旦你需要扩大部署，你就会绝望的发现扩展是如此的困难以至于几乎不可能做到。
归根结底，楼主最好能列出这个需求的根本原因，然后分析一下真正可行的方案，而不是一上来就认准要做“服务器连接客户端”。
1、网站运行在服务器A上
2、用户从自己的机器B登陆网站A
3、登录后，网站A的代码要连接安装在客户机B上的数据库
不知道我的猜测对不对。这种设计从架构上来说就注定是失败的。原因如下：
1、直接违反B/S应用的初衷，即简化客户端部署（客户端只需要浏览器即可）。在客户端部署数据库文件甚至数据库系统大大增加了维护成本，以至于可能还不如基于Window Form的C/S或者多层应用便捷。
2、从服务器到客户机的数据库连接很容易因为internet固有的特性而失败。首先如果你是用的是文件型数据库如Access，服务器基本是无法直接访问远程Access文件的。其次，即使客户端使用SQL Server Express这样允许远端连接的DBMS，也很容易受到防火墙或者NAT的限制。举个例子，服务器要想连接没有公网IP的客户机，是非常困难的，往往需要客户端首先驳接VPN。
3、Internet的弱连接特性，使得“服务器访问客户机”的数据访问方式极为不可靠并且低效（想象一下，服务器通过56kbps的拨号连接来连接客户机，并想要读取1MB的数据使用），最终的用户体验可能极为可怕，以至于没人愿意去用它。
如果这是一个基于LAN或者Intranet的应用，可能还好一些，因为你可以控制很多东西，但未来一旦你需要扩大部署，你就会绝望的发现扩展是如此的困难以至于几乎不可能做到。
归根结底，楼主最好能列出这个需求的根本原因，然后分析一下真正可行的方案，而不是一上来就认准要做“服务器连接客户端”。
#5
高人，谢谢，我也有这方面问题可考虑，可是就是有用户的变态要求，远程连接服务器，确实有很多弊端，谢谢你的明确提出，我会在考虑一下，再次感谢，再过一段时间，我在给分
#6
你这种方法，是不是通过Js脚本，获取客户端数据库的有效信息，是通过Js方法获取数据库数据吗？？
#7
我希望你把背后的需求详细写出来，也许我可以帮你考虑一下变通的解决办法。
举个例子，如果连接客户端数据库的原因仅仅是为了上传一些客户离线编辑的数据（很常见，比方说有些账务数据是在库房里用几台没有联网的电脑输入的，然后每天下班时把新数据保存到U盘上，用一台联网的机器上传到服务器上），你可以考虑开放数据上传功能。即将需要处理的数据在客户端先处理好（例如，找出新增或者删除、修改过的记录，产生一个增量变化数据集，用文本文件或者一个Access数据库存放），然后用文件上传功能上传到服务器端。服务器接收到上传的完整数据之后，可以进行在线或者离线的处理。这样要远远优于想办法建立从服务器到浏览器的主动连接。
举个例子，如果连接客户端数据库的原因仅仅是为了上传一些客户离线编辑的数据（很常见，比方说有些账务数据是在库房里用几台没有联网的电脑输入的，然后每天下班时把新数据保存到U盘上，用一台联网的机器上传到服务器上），你可以考虑开放数据上传功能。即将需要处理的数据在客户端先处理好（例如，找出新增或者删除、修改过的记录，产生一个增量变化数据集，用文本文件或者一个Access数据库存放），然后用文件上传功能上传到服务器端。服务器接收到上传的完整数据之后，可以进行在线或者离线的处理。这样要远远优于想办法建立从服务器到浏览器的主动连接。
#8
感谢你的积极帮助，项目暂时还在策划阶段，我们还需要考虑用户需求，并要和用户协商，我们在考虑新的解决方案。再次感谢你的回复
#9
晕，服务器能连接客户器的数据吗？内网还有点可能，外网除非是自己内部人员专用的，不然谁的机上有你要用的数据库呢，就算有受防火墙、网关种种限制你也可能访问不了
#10
你宁可做个上传页面给他把数据库传到服务器，然后再由服务器自动合并数据，远程连接本地数据库稳定性和可操作性太差了
#11
谢谢你的提议，我正在考虑，呵呵