access菜鸟七大邪门武器之1—DsoFramer让word、excel作Access的报表

ganlinlao

第6章、网络篇

2、Access作为客户端与web的交互能力的思考

          坦白地说，作为一个超烂的菜鸟，我总愚蠢地认为写任何一个access应用，都应该具有网络功能。没有网络功能的access应用更象是一种自娱自乐。甚至我悲观地认为，如果access不具有强大的网络交互能力的话，那么在不远的将来，它会很快走向消亡。而且我坚信，以后的Access应该具有很强大的网络交互能力，否则它确实没有多少存在的意义。微软在access2013中已经开始尝试了。

很可惜，在认坛里这么多年来，极少人谈及Access与网络交互能力。似乎太多的人坚定地认为access+SQLserver是唯一正确的方式。Access+SQL server是一种双层结构，有它的便利的一面。也有它的一些的局限性。这种局限性包括：SQL server的安装问题（在一些很小的应用中，这会是一个问题，其它的不算是问题）。在线更新问题，拓展性问题（拓展起来不方便），office文档管理问题（我了解到不少人尝试想利用sqlserver的filestream读取word或excel文件，但似乎问题很多而不可行），图片等资源的更新问题……

    虽然我们在access经常使用com组件，整个windows到处都是，而vba也只支持com的对象。但com本质是什么？我个人愚蠢地认为com的核心能力之一是聚合能力。通过组件的聚合，通过接口，达到简便地复用。而且我个人愚蠢地认为网络的核心功能之一就是聚集能力。不管是xml，webservice，还是其它的让人眼花缭乱的新技术，无非都是为了方便数据的聚集。在这一点上com组件和网络有着惊人一致的一面。

       当谈及access与web网络交互能力时，有几个概念是一定要厘清的。

1、有状态和无状态。Access与sql server的连接是一种有状态的连接。而access与http的连接是一种无状态的连接。但websock的出现可能会改变这种情况。

2、字符集。整个windows都是采用gbk字符集，access和sql server也是默认以gbk作为默认字符集，但web上，gbk只是一种可选的字符集，更多的是采用utf-8字符集，很可惜vba没有简便的函数处理utf-8字符集。

3、缓存问题。尽管access也有缓存，只要你打开一个mdb或acced，缓存就一定存在。但这个缓存和浏览器中的缓存，是两个概念。
4、同步和异步：access打开本地的mdb或acced，access打开sql server，所有的recordset默认是同步的。尽管你可以使用异步，但我很少见到有人使用异步。但在web的数据交互时，异步但会成为一个异常重要的问题。
5、相对路径和绝对路径：

为实现Http访问，微软提供了这么几种API：
（1）Winsock，工作于网络层和传输层的开发库，对于编写TCP，UDP，以及原始IP通信程序非常合适。函数原形也基本符合Unix socket标准。Windows平台上的大多数程序，如QQ，讯雷等都基于其开发。
（2）ws2_32，是Winsock的升级版本，在兼容的基础上增加了不符合Unix socket标准，但更适合Windows平台的库函数，一般以WSA*开头。
现代的大多数Windows平台程序也都开始依赖于此库。
（3）WinInet，Windows Internet扩展库，工作于应用协议层，提供了http，ftp，gopher协议的实现，为基于以上三种协议的程序开发提供基础平台，需要说明的是，尽管WinInet工作于应用层，但其本身wininet.dll的实现并不依赖于winsock.dll或ws2_32.dll,而是独立存在的。至少目前的版本是这样。基于WinInet的应用程序最著名的例子就是IE了。
（4）WinHttp，也是工作于应用协议层，提供了http协议的实现。看起来与WinInet有重复的部分，没错，WinHttp就是为了替换WinInet中的http部分的，它更加健壮稳定，而且还为http服务器端开发提供了库函数。如果进行现代http的开发，建议使用WinHTTP而不是WinInet。使用WinHTTP进行开发的著名例子就是Google的浏览器Chrome，但是Chrome2.0以后版本google放弃了winhttp而是使用了自己开发的http库，这也是为了使chrome实现跨平台的重要举措。另外，WinHttp.dll也不依赖于winsock或ws2_32，也是独立运行的。
如果基于socket编程的话，Winows平台与其它平台函数基本相同，实现跨平台比较容易。
wsock和wininet或winhttp也可以同时使用。


WinInet HttpSendRequest使用的事项

   HttpSendRequest不支持异步模式，虽然API文档说可以，但是在其它官方文章中已证实不可以；要用异步方式完成任务，需要通过使用线程来自己封装。
   HttpSendRequest使用的INTERNETHANLE要每次通过HttpOpenRequest获取，不能重用，否则可能会出现无法读取返回数据或数据重复等错误；虽然API文档说只要每次把上次的数据取完就可以，但这是经历了无数痛苦的unit test后换来的经验。
    发送httpSendRequest后，需要使用InternetReadFile来读取，重复多次读，直到返回数据为0byte为止。
    错误代码在http://support.microsoft.com/kb/193625  ，API文档中找不到。

什么是WinHTTP?
WinHTTP的全称是Microsoft Windows HTTP Services,它提供给开发者一个HTTP客户端应用程序接口(API), 通过这种API借助HTTP协议给其他的HTTP服务器发送请求.
WinHTTP支持桌面应用程序, Windows系统服务, 和Windows服务器端应用程序.
对于基于Microsoft.NET Framework的应用程序, 不推荐使用WinHTTP服务, 因为.NET Framework应用程序应该使用在System.Net命名空间下的网络基础设施类型.
WinHTTP提供了两种编程方式, 一种是CC++的API, 另一种是COM组件.
WinHTTP与WinINet的区别
================
WinHTTP被设计为主要应用在服务器端应用程序的场景下, 让服务器端应用程序访问HTTP服务器.
WinINet是一种更老的技术, 它被设计为一个HTTP客户端平台, 用于交互式桌面应用程序, 比如说IE, Office等.
服务器端应用程序要求HTTP客户端服务使用WinHTTP而不是WinINet.
WinHTTP和WinINet在微软是由不同的团队来提供支持的.
WinHTTP与Proxy
================
如果HTTP Proxy需要认证(authentication), 那么HTTP Application会收到407(proxy requiresauthentication). 除了这个状态码, 代理服务器还会发送一个或更多的authenticate headers:“Proxy-Authenticate”. 这些信息足够我们在network monitor trace中鉴定HTTP无法访问是否是由于proxy需要认证引起的了.
WinHTTP的proxy配置是存储在注册表键
HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionInternetSettingsConnectionsWinHttpSettings
当中的, 修改和查看需要使用一个命令行工具proxycfg


下面来说说实现Http访问的流程（基本上都一样的流程）：
1， 首先我们打开一个Session获得一个HINTERNET session句柄；
2， 然后我们使用这个session句柄与服务器连接得到一个HINTERNET connect句柄；
3， 然后我们使用这个connect句柄来打开Http 请求得到一个HINTERNET request句柄；
4， 这时我们就可以使用这个request句柄来发送数据与读取从服务器返回的数据；
5， 最后依次关闭request，connect，session句柄。

ganlinlao

占位

左耳fwlb

占位学习。

zaohua

为何第一个程序新建出现错误？

lijiejoy

赞，大赞。

fshlxy

哦，这个是个好东西啊1

34acc

32个赞

ly

内容丰富，收藏后慢慢品尝学习，谢谢！

hunrybecky

支持ACCESS在线就好了。

gujin162

此贴必火，占位留名，众亲平身