浅谈Access结合SQL SERVER开发的几种方式

zhu_terry

本文将介绍几种Access结合SQL SERVER作为后台数据库来进行开发的方式，笔者接触Access时间不长，1年不到。若文中有错误之处，还请广大朋友回复，大家一起交流，共同进步。

        首先，既然是Access开发为何要用SQLSERVER作后台数据库？Access本身就是一个数据库，又用SQL SERVER来作后台数据库岂不是把问题复杂化？关于这个问题，以笔者自身的经验来说，主要涉及以下几点：

1）  需求的变化，一开始可能做的系统比较简单，功能也少，但是要知道需求总是在不断的变化的。随着功能的不断增加，数据量慢慢变大，以Access作为库来存储数据就显得有些难以胜任了。于是，寻求性能更好的数据库便是解决办法的思路之一。这个时候，自然同为自家兄弟兄长的SQL SERVER就是首选的对象。

2）  可能会出于安全的需要，虽然说Access不能说一点安全性没有，但是还是上面的一条，需求总是在不断变化的，当数据量变得越来越多，安全性就变得很重要了。万一Access数据库崩溃，数据安全就难以保证。当然安全是没有绝对的安全的，但是在相对的环境下，选择安全系数，稳定性也更高的SQL SERVER数据库，便是一个选择的方案。

3）  使用的人数增多，当同时使用的人数变得越来越多的时候，恐怕Access作为库来使用就更显其弱势了，作为一个文件型的数据库，同时打开的人数一旦过多，并发访问所生的影响就会变得非常大，此时使用服务器类型的SQL SERVER也是逼上梁山的无奈选择，当然也可以选择其他的服务器型的数据库，但综合来看，作为兄长的SQL SERVER是一个不错的选择。

下面笔者详细介绍一下我所知道的3种结合SQL SERVER的方式

第1种方式：ADP项目

ADP项目是一种与SQL SERVER结合的方式，但是可惜啊，自Access2010版之上（2010版还是支持的）就不支持了。刚才说了笔者接触Access也才1年不到，至于微软为何会放弃ADP这种技术，说实话笔者也不明白其中的深层次原因，可能微软认为这种技术太过鸡肋？亦或者这种技术还是存在不少的短板？又或者是微软为了推广新的技术而放弃了此项技术？但是据网上的资料来看，在Access2003的时候，有不少结合SQL SERVER的项目都是采用ADP技术来进行开发的，可见当时ADP还是一个很不错的选择。至于微软为何会放弃，实在是不知道，其实我也不想知道。以下是笔者从网上搜索到的描述ADP一些优点的描述

ADP有如下优点:
采用ADPmj 在Access中就可以编辑表的结构,而在MDB 中链接到服务器的表是不能直接修改的。
利用ADP,一个联结就可以访问到所有的数据库项目,而MDB则不行。比如窗体上有3个组合框,它们列表的行来源都是表。如果采用MDB加链接表的方式,那么就需要3个与数据库的联结。而对于ADP 来说,一个联结就行了.
.ADP开发方案与其他各种客户ー服务器开发方案相比,更为简单方便,而且成型更加快速,开发速度也更为快捷。

与MDB 和其他C/S(客户一服务器)开发方案相比,ADP的缺点如下:
.ADP 只能与SQL Server一起工作,不能使用其他的数据库,如Oracle 和 Sybase.
而MDB 则可以利用ODBC 与大多数数据库一起工作,甚至是MySQL,Interbase
等一些数据库管理系统。
使用ADP不能存储本地表和查询。MDB 则可以通过链接表的形式链接本地 MDB
和其他数据库.

第2种方式：链接表

链接表这种方式相信很多开发Access的朋友都非常熟悉。Access的一种开发方式就是一个Access文件作前台，另一个Access文件作后台。后台的那个文件一般是放在共享盘上，前台文件分发至每个使用者，基本上小范围、局域网都是这样去操作的。那么后台如果采用SQL SERVER数据库呢？同样也可以采用链接表的方式，只是此时链接的是SQL SERVER中的表，网上关于这方面的资料也非常多，以下是笔者自己开发的系统中抄袭改造网上下载的一个链接表管理窗体后，自动完成的链接表。如下图所示，可以看到链接SQL SERVER的链接表的样式也链接Access的有所不同，是一个类似地球的小球状图形。而链接Access的链接表则还是表格的图形状，两者前面都带一个小小的箭头。链接表创建完成后，在Access中就可以像使用普通表一样去使用了。个别细节会稍稍有所不同，比较复选框的是/否字段。但基本上与使用普通Access中的表无异。这也是笔者目前工作中所采用与后台SQL SERVER结合的方式，也是较为推荐的一种方式，因为这种方式从刚才所讲的2个Access文件配合的方式来说，学习的成本不高，且使用习惯几乎无需做大的改变。但是，如果你的数据量很大的话，或许采用这种方式可能会有一定的问题，因为我目前还没有碰到数据量很大的情况，所以这个问题还没有暴露出来，因为我考虑如果后台SQL SERVER表中如果某些表的记录条数非常多，字段数也比较多。直接这样链接过来，会不会在开发时对性能有一定的影响还真不好说，有碰到的朋友可以说说自己的感受。

zhu_terry

第3种方式

采用ADO对象，直接与后台SQLSERVER数据库进行交互。

采用这种方式的话，我想说的是这对一些Access的开发人员是不太友好了。我是这样使用的，因为这方面我的经验实在不多。

        首先我会建立一个模块就叫modDB吧，在该模块中声明的一个模块级的连接对象

Public conn AS object

再写一个函数去连接后台的SQL SERVER数据库。

Public Function ConnDBSqlServer() AsBoolean

   Host = ".\sqlexpress"

   UID = "sa"

   PWD = "123456"

   DBName = "simt"

   Set conn = CreateObject("adodb.connection")

   'myData = ThisWorkbook.Path & "\TD.mdb"    '指定数据库

   

   With conn

       .Provider = "SQLOLEDB.1ersist Security Info = False;User ID=" & UID & "assword =" & PWD & ";DataSource =" & Host & ";Initial Catalog =" & DBName

       .Open

   End With

   

   If conn.State > 0 Then

       ConnDBSqlServer = True

   Else

       ConnDBSqlServer = False

   End If

   'Debug.Print conn.State

End Function

再来一个断开连接的函数

Public Sub DisConnect()

   On Error Resume Next

    '判断连接对象是否实例化

   If IsNull(conn) Then

       Exit Sub

   End If

   

    '判断连接对象状态

   If conn.State > 0 Then

       conn.Close

       Set conn = Nothing

   End If

End Sub

再封装一个函数得到select 查询的结果集

'得到select查询后的结果集对象

Public Function getRs(ByVal strSQL) AsObject

   Dim rs As Object

   Set rs = CreateObject("adodb.recordset")

   rs.Open strSQL, conn, 1, 3

   Set getRs = rs

End Function

使用的时候，新建一个窗体，放置几个文本框。编辑文本框的绑定值与strSQL语句中的字段的名称，如有别名时需要与别名一致。在窗体的Load事件中可以这样写

Private Sub Form_Load()

        DimstrSQL As string

        DimformRS As Object

   strSQL = "select * from myTable"

   modDB.ConnDBSqlServer

   Set formRS = modDB.getRs(strSQL)

   If Not IsNull(formRS) Then

       Set Me.Form.Recordset = formRS

End If

modDB.Disconnect

End Sub

打开窗体后就可以发现，已经能够得到数据了，但是此时是无法编辑数据的，Access提示窗体是只读的（截图没有显示出来），窗体的数据表视图也能显示数据

所以采用这种方式也能和SQL SERVER进行交互，但是我认为这种方式已经背离了Access快速开发的初衷，因为Access的窗体和其他windows编程工具所提供的窗体对象最大的不同在于其和数据源的绑定是极其密切的，可以说是Access窗体的一大特色。如果是动态集的方式绑定的某张表的话，新增、修改数据都非常方便，甚至不需要编写代码，就算要编写代码也只需要简单的调用几句。最简单的保存修改的记录可以一句话Docmd.runCommand acCmdSave就搞定了。而如果采用这第3种的方式与SQL SERVER进行交互的话，代码量会非常大（当然如果前期做好一定的函数的封装，其实也可能还好），在这种情况下Access已经变成了和VB，VC，Dephi，C# Winform等工具没有本质差别的了。此时我的体会是我还需要Access作什么呢？仅仅只是一个前台的工具而已了，而这个工具相比windows其他的编程工具或者在第3种的方式下也不见得有太大的优势，快速开发的特性一点儿也没有了。那此时我还用Access做什么？

做梦

平台似乎是链接表+ADO的方式

accben

如果不用链接表，纯用ADO，那么用ACCESS开发就差不多相关当用VB开发了。

用链接表简单多了，ACCESS建查询、窗体、报表、各种绑定，so easy!