用ADP的高手们，是绑定表还是使用SQL语句处理窗体？

lshstruc

我不是adp高手，这个论坛里的朱以文老师是，我是个爱好者，也谈一点看法：
1.楼主提到的，某开发平台提到的ODBC链接表方式实现C/S，如果采用绑定表会慢的说法，我也注意到了，而且这个说法很早就提出来了
2.我对adp与ODBC的性能与优越性比较问题学习了很长时间，各专业论坛上对于这个方面的讨论也是吵翻了天，各有各的意见，各领军派人物都有自己的看法。
3.论坛里力挺ADP的有朱老师，事实上截止到acc2003为止，microsoft也是力挺adp的。我记得有本英文acc开发宝典里面大概是这样说”odbc链接表是工作组内部实现C/S的一种可接受的解决方案，但ODBC链接表本质上仍然是以客户端为中心的，要建立以服务器为中心的C/S程序，应对多用户并发和海量数据，应该选择升迁。
4.但是实际应用中，很多人认为ODBC是优于ADP的，这中间不乏高手，而且你仔细观察会发现，现在做的比较成熟，模式比较固定的商业版本，基本上都是”ODBC链接表为基础+ado“的模式开发的，比如UMV开发平台，本站的王站的高大上的BEAT版，歌逸的平台（根据介绍未使用过不肯定）。当然，这里面有商业化，批量化，模式化需要的原因在里面，不仅仅是优越性，速度的问题决定的。
5.开发者的灵活和才智，odbc+ado模式,把access用到了极致，基本上都是窗体绑定表或查询并带上条件避免全表取数，只用来展示数据，不用来录入，录入又采用非绑定表，ado读写，避开ODBC直接与SQLSERVER取要用的少量记录。这种模式既充分利用了acc直接绑定表窗体代码少的优越性，又充分避开了绑定表录入要打开表加载表的弱点。
6.在acc的开发宝典里面，把传递查询作为odbc链接表方式访问SQLSERER推荐的方式，但实际上，极少有人在用这个东西，有人宁肯多写代码用ado取记录集然后绑定到窗体也不愿意用这个，而且网上对于这种技术的资料极少。
7.我试过传递查询技术，包括传递查询的写法，参数的传递方式，VBA创建传递查询等，其实非常好用，也比链接表效率高，但传递查询不能绑定到窗体作为录入窗体，我曾经有个想法，就是全篇使用传递查询来做开发，希望以后试试。
7.实际上我认为，acc最大与其他软件最大的区别就是1.绑定表，2.主子窗体，这也是acc最核心的优越性，没有了这两样，你还会用acc吗？
8.我看到的还有一些其他的开发模式，纯ado模式，适合于少数人，对性能，灵活性高度重视，对代码不屑一顾的人使用。
9.关于绑定表速度慢的问题，我认为不仅仅是odbc链接表的问题，放在adp里面是一样的，也会慢，这个应该主要是数据量造成的，楼主看到文章后，我昨天上午也看到了，我马做了一个测试，adp环境，窗体绑定一个170W条记录的表，直接打开窗体然后直接gotonewrecord,花了10S时间，环境WIN7+ACC2007+SQL2000，SQL是本地服务器，从硬盘存取数据，想想如果放在局域网里，得要多长时间打开？
10.在ADP中，C/S架构基于OLEDB，当通过窗体访问数据时，OLE DB 会从 SQL Server 数据库检索一个可更新快照的记录集，并在客户机上缓存这些数据，当处理窗体或数据表中的数据时，不论是浏览、筛选、排序、查找数据，还是更新数据，都是在处理缓存在客户机上的数据。
11.其实在acc中，绑定表方式访问数据库是微软推荐的方式，也是ACC的特点，对于绑定表会带来大量数据传输的问题，microsoft肯定能考虑到的，adp的窗体属性里面有一个dateentry属性，也有一个SERVERFILTER属性，新增记录时，把DATEENTRY属性设为true，窗体不加载任何数据直接打开，编辑记录时，利用SERVERFILTER属性，只取你要的记录，不加载全部数据，一点都不卡。与非绑定方式录入没有任何分别。我用176W条记录做了实验，新增和编辑都是秒开。
12.在mdb中，没有serverfilter属性，但是可以在打开窗体时设置DATEMODE为acformadd，和限制where条件，也是microsoft设计来应对绑定表加载数据问题的，我没有做实验，不知使用后效果与非绑定窗体如何。
13.acc为前台，后台还是ACC的模式下，局域网联网使用，除了数据量的问题，还存在一个记录锁定的问题，更加造成慢和卡的问题。
14.我觉得，我观察很多学acc的人，都过于偏重用vba代码，用dao，用ado解决问题，而对microsoft为我们提供的大量的acc自身自带的功能，属性，工具，控制办法，弃之一边。造成这种的原因我觉得主要有两个方面，第一是对acc自身特性不重视，对强大的MICORSOFT不够崇拜，第二是思维习惯不喜欢从方法上去解决问题，而习惯于从技术上与解决问题。
15.我现在做程序，都是自己企业用，我一直用的adp，我坚持一个原则是，能用acc自身功能实现的，坚决不写代码，能用自带控件解决的，坚决不引用第三方的，能利用窗体解决的，坚决不用ado，不在同一个界面上，实现过多的功能。尽可能做原生态的程序，主要做的好处是，1.稳定，2，bug少，3，好维护，4.软件分发后，没有什么乱七八糟的丢失的引用之类的。5.以上说的是我个人做程序，像专业的软件开发平台之类的，考虑到统一性，通用性，甚至自动生成，考虑的角度肯定和我是不一样的。
16.对于很多实际问题，其实以上谈到的几个开发平台都是专业的搞商业软件的，有的甚至搞了超过10年了，积累了大量的实际使用经验，对ACC的理解深度肯定和我不一样的，他们不建议绑定表肯定是有成熟经验的。
17.乱七八糟说了一段，非常不专业，纯粹给本站涨涨人气，凑凑热闹。

lshstruc

补充楼上LAIMF的第三条：
非常赞同楼上的处理办法，ODBC链接表处理纯数据，根据我的了解，速度还是挺好的，对于一个表中比较大的字段，不建议放在同一个记录集中打开，楼上的通过ADO来根据记录的主键单独寻找该字段，是一个好办法。
其实ACC的绑定窗体自身是支持绑定字段以外的控件的，绑定窗体上的控件除了绑定到字段，还可以绑定到表达式，而这个表达式是支持与绑定字段的控件联动的。
而对于该绑定表达式控件的值，是根据绑定字段计算得来的，microsoft的强大就在于，啥都替你想到了，如果你的记录集中有1000条记录，他却不会把1000条记录对应的表达式全部计算出来，然后放在内存里，他是这么处理的：
1.单个窗体：仅根据窗体当前记录计算对应的控件值，跳到下一条记录，重新计算下一条的控件值，并清除上一条的控件值。
2.连续窗体和数据表窗体：仅计算当前屏幕上显示的记录对应的控件值，通过滚动条滚动到下一页，重新计算下一页的控件值，并清除上一页的控件值。（19寸的屏幕和20寸的屏幕计算的量也是不一样的，窗口最大化和缩放后计算的量也是不一样的，很有意思）。
所以完全不用担心卡的问题，我没有处理过图片的问题，但是我处理过一个“备注”字段，用的也是这种方法：
1.窗体绑定到记录集，记录集不包含备注字段。
2.建一个非绑定的控件，直接用ACC自带的域聚合函数，控件值=DLOOKUP()，根据窗体绑定的记录ID查阅备注字段。
以上方法没有一句代码，没试过图片，不知能行不。
缺点是DLOOKUP 可能比自己写的ADO代码稍微慢，但完全用acc自身功能，基本不写代码，简单，稳定，可靠。而且支持数据表窗体和连续窗体，自动联动，特别适合我这样的懒人。

lshstruc

memphis230 发表于 2015-4-9 23:13
哥，我觉得dlookup等D类函数只能在不想动脑精的时候用，那速度是慢得出奇的，宁愿用个组合框或列表框，在 ...

以上说的主要是子窗体中一次加载大量记录，把图片字段或备注字段与记录集分离，按需求调用的方法，主要是为了避免子窗体一次加载记录量过大，网络带宽的造成速度慢。
域聚合函数的慢与数据流量控制不好造成的慢不是一个概念。