记得两年前，我曾发表过一篇文章，是关于评价ACCESS比DELPHI做数据库要好的内容，当时引起了很多人的争议。都说我的不是。我深知道，要拿ACCESS和DELPHI来比，DELPHI不论在界面设计、编译方面、语言等方面都比ACCESS好得多。
但各位玩DELPHI的朋友们，你们对ACCESS了解又知道多少？现在我要用事实来告诉各位玩DELPHI的朋友们，我为什么要持这种理由？ DELPHI，做数据库，也许大家都经常要用到SQL，这是正确的，我用ACCESS也不例外。但不知道大家有没有这种感受，SQL语句要看它时，短短几行还可以，但一个SQL要连接几个表时，语句就会很复杂，加上表达式、条件等等的内容，可以看到你头晕。
ACCESS，它把一个SQL显示为设计视图，要设计的查询内容都可以在设计视图上看得一清二楚。对某些大型的复合查询，可以分为多次设计求得。例如：
Select a,b from tab表1; 保存为 qry1
Select a,b*2 as n from qry1; 保存为 qry2
Select n from qry2; 大家千万不要少看这个平淡无奇的东西，我用VB做过数据库，都知道VB并不支持这种功能。但事实上，这种功能在大量的开发中，正是经常要使用的东西，经验告诉我，有时要做一件事，要用四个以上的复合查询才能完成，有时还是多重复合。
这种SQL拆分，使调试和编写SQL难度减少了很多。而且又使大型项目的SQL重用变为可能。所以我做数据库到现在，也不把精力放在SQL的语法上，做SQL，也只是用心的在设计视图做和分析要求解的问题，对于SQL的语法，我不在乎，在必要时，才看看帮助。在网上看到这么多网友问这个SQL为什么错了，那个SQL不能执行，我心里就好笑，有了ACCESS，还有必要这样问吗？简直就是在浪费时间。
———————————————————————————————————————
玩过POWERBUILDER的人都认识嵌入式SQL，所谓嵌入式SQL，就是SQL中可以直接使用代码中的自定义函数，直接引用窗体元素。大家也可能经常碰到条件查询，而条件查询中的条件又和窗体中的文本或选项框等控件有关联。
没有嵌入式SQL，就要把一个数据集的SQL属性重新设为窗体元素的属性，再刷新这个数据集。
Sql1.SQL=”Select * from tab1 where (x=” & txtData.Text & “)”
Sql1.requery 但有了嵌入式SQL，当改变txtData.Text时，我们只要执行一次sql1.requery就可以了。SQL根本不用重设定。嵌入式SQL是一种聪明东西，它的SQL写为”select * from tab1 where (x= form1!txtdata.text)”就可以了。
开发经验告诉我，SQL和窗体元素关联的情况实在太多了。
没有嵌入式SQL，写数据库软件就要写出很多额外的代码。经常看到别人的软件的源代码，都有一大堆这样的东西。更复杂的SQL和更复杂的窗体元素关联，可以说是更可怕的折磨，没有了它，重设定SQL就是在做一件没有意义但又必要做的事情。
SQL中可以直接使用自定义函数，这个功能，我早就明白到它的妙处，有了它，原本一些要编写一堆代码做出来的东西，现在也不需要了。直接写一个SQL就OK了。它的更绝之处就是很多的时候可以代替用FOR语句来检查一个记录集的每个记录。当中的好处，一定要大家用过，才能体会。如果没有了这种功能，可能等待你的就是一大堆一大堆的代码。
我可以告诉大家，光是上面的两个理由，就可以使我放弃DELPHI而选择ACCESS了。如果要我继续说下去，还是有理由的，就是DELPHI在数据控制的界面上，也不如ACCESS。 做数据库时用到表格中的下拉列表，这可是经常要用到的功能，大家都知道一个数据库项目中，数据表都有着多层次的关系。很多的时候，我们都希望在数据表格中有一个下拉列表，下拉列表是基础数据表的内容。当我们点击相应的列后，出现这个下拉列表，选择或输入相应的内容。很可气，DELPHI本身不提供这种控件，这种经常用到的东西，也要用到第三方控件。而第三方控件，本身又有些小毛病，有时输入中文又有些问题，有些又有莫名其妙的错误。
而ACCESS的概念，数据表本身是一个子窗体，子窗体有数据表视图，这种视图本身又是我们想要的内容，设计这些东西，可以说是十万个方便。
DELPHI并不支持控件绑定其它控件属性的功能。例如，用文本框显示List1中的Count属性，就要：
TxtData.Text=List1.Count
当List1的Count属性变动时，就要重新执行上面的语句一次才保持文本框所反应的内容正确。
而ACCESS的概念，每个数据控件都有绑定值，绑定值可以输入一个表达式，表达式里是直接的代码。当List1的Count变动时，文本框就会自动更新，无需你的操心。
再继续下去，就是ACCESS的窗体概念也值得一赞，窗体本身可以包含一个数据集，窗体也可以包含其它子窗体。设计数据库时也得心应手。…… 我同时也知道，ACCESS的局限性也很大，它不能生成EXE，开发大型数据库短处就很多，安全性也不好。语言方面也是使用VBA，VBA本身又没有真正的面向对象能力。
但我却感受到，ACCESS其实是一种真正的可视化数据库开发工具，它和旧的数据库开发工具比，多了很多的长处，我也发现，很多原来是FOXPRO、VB的数据库开发员，已经越来越多的正转向ACCESS了，因为他们都聪明，明白到这点。 我认为：DELPHI和ACCESS在数据库方面比较，就如VC6.0和VB1.0相比，DOS和WINDOWS 1.0相比,DOS成熟，但已经是落日黄花，WINDOWS幼稚，但却是拥有生命力的新事物。有空大家也可以看看ACCESS的人气…
http://www.access-cn.com http://www.accessoft.com不如大家认为如何？
但我坚持自己的观点，我认为是对的，实践中也是的确是这样。为什么还要抱否定的观点？我劝劝那些死抱一种想法的人，花些时间看看ACCESS，再评论也不迟。不要以为OFFICE中的东西就做不了什么，OFFICE也好，开发工具也好，只不过是称呼而已，看事物就要看它的核心价值。别人也可能认为我是井底之蛙，做些小数据库之类，但我从这些小小的项目，也看出了ACCESS那种前所未有的潜力。这点，DELPHI一定比不上。
我所看到的潜力就是：更简单，功能更强大的数据库开发工具必定存在，而ACCESS就是这种强大工具的雏形，我在这里不说语言和其它方面，但光是上面我所说的SQL的特性，DELPHI就已经做不到了，这不是潜力么？？
我打赌，如果微软有心把ACCESS做强，相信做数据库的人都跑到ACCESS这边。
编程小子) :怎么解释呢？
2. 如楼主所述，access不能生成exe文件，总不能让客户在office环境中干活吧？还不算客户端office的价格。
3. 恕我直言，office自office2000以后就多了很多自作聪明的特征，比如中文系统里access里自动开启输入法的做法，实在是匪夷所思。说句气话，我要是买了微软，第一件事就是把office踢出去。这里个人偏见多点。
4. delphi可以用来开发绝大多数数据库应用，而office中的access只能开发access格式的数据库应用，先天不足（access的安全性，大规模应用时低下的效率），能说什么好呢？不管office里的access开发套件功能多么强大，在大型应用中是绝对没胆子使用access的——当然我也承认，开发一个轻量级的系统比如家用系统，使用access格式还是比较好的选择。
其他地方呢？
情人眼里出西施，恐龙也说是美女。
也许真的要看场合来评论，每个东西都有其优点也有其缺点。
我们看问题要用一分为二的观点。
不要研究了几年的ACCESS就说它好，人家MS专家开发它出来还不敢说它十全十美呢！
作 者： LWWANDVB (编程小子)
千万不要轻易下定论说谁好，谁不好。我说郑海霞长得比关芝琳漂亮，你能接受吗？
你能接受，那别人能接受吗？反过来，我说关芝琳打篮球能打得过郑海霞，那只有鬼才相信了。以上我首先要向郑海霞和关芝琳道个歉，希望两位看到本贴不要怪我才好。
不同类的东西嘛
Sql1.SQL=”Select * from tab1 where (x=” & txtData.Text & “)”
Sql1.requery在delphi中这样实现
Sql1.close
Sql1.SQL='Select * from tab1 where x=''txtData.Text'''
Sql1.open在你否定一件事物之前，你必须先去了解他，若在一知半解的时候就去否定他，别人会认为你是愚蠢的。别外，delphi不是拿来写sql语句的工具，写sql语句完全可以用SQL查询分析器，调试起来也比Access简单，要知道知道的sql高手大部份时间是不需要用工具来写sql的，为什么？因为工具写出来的sql执行效率是最低的。
TO hexenzhou(甲骨文) ：
你到www.access-cn.com 注册一个用户，那里有一大堆的ACCESS做的软件。企业ERP的也有，大家去看看吧。WWW.ACCESS-CN.COM
WWW.ACCESSOFT.COM
Select a,b from tab表1; 保存为 qry1
Select a,b*2 as n from qry1; 保存为 qry2
Select n from qry2;
楼主大概不知道sql server有视图的功能吧，你认为这些有必要写得这么复杂吗？你知道你写出来的语句运行效率低是为什么吗？那是因为你太依赖工具了。Select a,b*2 as n from tab表1
完全可以达到你要求了，为何非要写得如此复杂呢？
TO hexenzhou(甲骨文) ：
你到www.access-cn.com 注册一个用户，那里有一大堆的ACCESS做的软件。企业ERP的也有，大家去看看吧。WWW.ACCESS-CN.COM
WWW.ACCESSOFT.COM
你见过企业ERP应用中有用ACCESS的吗？
当然易学易用和全中文也是其中之一。
但这点不重要，重要的是ACCESS的真正的数据库的可视化概念。DELPHI是十分强大，DELPHI有这种概念吗？？？
楼主你怎么不拿“学习机”与PC相比呢，学习机上的游戏丰富得不得了啊
这两天研究压缩算法搞得我头都疼，delphi真的不如winrar呀。
********************
我喜欢这位仁兄的比喻，呵呵。
这是因为你使用的工具的级数不够高，还不够完善，所以执行效率低。关于你所说的效率，我有一个见解：
为什么你们用DELPHI写程序，而不用汇编写？汇编不是执行效率最高的么？其实道理很简单，用汇编的执行是最快，但程序一大，你就麻烦了，所以就要用高级语言，高级语言之能够实现低级语言的东西，是因为它能把高层次转为低层次的东西。而执行效率，是这个高级语言内部转换为低层的实现的好而坏，本身就和高级语言是无关系的。我认为：SQL是数据库低层的语言，查询视图是数据库高层的语言。将来的趋势一定是这样。而且我已经不是一知半解，我也了解过你们写SQL的方式，ADO和BDE也接触过，说出来的是也是经过深思熟虑的说话，ACCESS最可贵之处就是把数据库这个概念和它也融合在一起，你明白吗？
如果access的这种开发方式能开发出，效率和规模至少不比delphi低很多的系统来（仅数据库这一方面就行）。我想这里的大多数兄弟都已经开始学习了，更不要说反对您了。至于前景吗?有谁说得清呢?即使代码自动生成的技术很成熟了,应该也有别的开发工具出来了吧。我想M$给access的定位应该不会是开发工具.
有点强辞夺理了!
我向来鄙视搞数据库的人??能说这句话,说明你是真的无知道,以前我也觉得搞数据库没什么,
可是对一个应用程序的企业来说,数据安全是第一位的,程序倒其次,你说说,是你这个做程序的
重要,还是数据库管理员重要!
***************************************************
切，DELPHI只能用来做数据库程序吗，企业只能用数据库软件吗！！
告诉你，上面的那个复合SQL只是一个例子，当然这么简单的东西要写为几个是多余的，但有些SQL是十分复杂的，把它拆为几个时，这个方法是最好的。拆为几个时，更易调试和维护。只于效率，只不过是工具实现你要的目标的方法问题，这就关系于工具的好与坏，与设计的人无关。TO：htyx(轻风夜私语)
告诉你，ACCESS的优点就是高层次上做高层次的东西。它是集中于数据的概念和开发员要开发的东西，而不是慢慢的写代码，写SQL，所以这点ACCESS绝对优于DELPHI的。
为什么ACCESS不能和DELPHI比较呢？？ACCESS是做数据库的（尽管是小东西，也是数据库），而DELPHI也号称是做数据库十分强大的工具，我看未必，因为它还不是真正的数据库的开发工具。它没有以上我说的ACCESS的强大特性（尽管还幼稚）。所以我就要非说一说不可。
TO： xzhifei(星级饭桶(抵制日货)·飞)
告诉你，在这里我只讨论做数据库。
数据库开发是Delphi的一部分功能，难道你看不道Delphi7上VCL面板上除了数据库还有很多其他控件吗？用Delphi写的软件，用access肯定写不出来，用access写的软件，用Delphi绝对可以做的比access更好.
TO： RcSoft(梨花剑雨)
我知道ACCESS有很多局限性，如果我认识POWERBUILDER，我一定用这个东西比DELPHI的。因为它也有着数据库的RD特性。
用ACCESS比，不是我无知，而是我深深体会到ACCESS告诉我的一种真正可视化数据库开发的感觉！！这种感觉，在别的开发工具是找不到的。
为什么要鄙视搞数据库的人？？搞数据库也要很强的逻辑思维呀，大型的项目中，更加要仔细分析，软件是面向企业应用的，更加是千头万绪，做一个数据库软件也要多方面配合才做得好，我想你也把别人看扁了！！TO： htyx(轻风夜私语)
我知道，MS是不给搞强ACCESS的，但ACCESS是第一代的数据库RD工具，从ACCESS 97 就开始了。
以后，可以看到更加多的数据库RD工具，当你们用着这些工具的时候，就会明白到今天我所言是真的了。你们的数据库开发工具—DELPHI，只不是相当于开发语言中的汇编罢了。
TO ：getit911(Windows转Linux中)
不不不，控件和开发工具根本不是一回事，就算控件多么的完善，使用起来也不及开发工具本身所提供的功能这么好，因为它们根本是两件事，可以说，控件只是补丁，开发工具本身才是真才实料。我可以打个比喻，就以EPSON C43和HP 3558比较，两种打印机中，HP 3558很好用，EPSON C43缺点很多，但EPSON C43可以改装，改装的东西，绝对没有本身就是好的东西这么好用。 因为打印机是高科技产品。
——————————————————————
不过我真有些………………，好了不在讨论了
在下愚昧，还是搂住厉害!
——大家不觉得这句话有语病么？再看看楼主的正文：“各位玩DELPHI的朋友们”“玩过POWERBUILDER的人都认识嵌入式SQL”
——一个“玩”字足以说明一切，由此可以看出楼主对数据库、软件的开发工具所抱的态度，仅此而已。看了全文，我直观的印象是，楼主是个某些方面的思路还不很清晰的人，也许还是学生一族。（因为学生气十足的人，才比较容易陷入“非黑即白”的简单化思维之中，呵呵）
TO: whxxr(彬彬)
为了真理，我并不累。我知道ACCESS的数据容量是很有限。我当然希望它能更强。但你知不知道，ACCESS是可以只做前台，后台是可以用SQL SERVER的。TO：cyactiveboy((冷酷有情))
告诉你，做一个企业系统（就如进销存），每个窗体都实现不同的窗体功能，所以说，SQL数据集一般在不同的窗体中要做到重用，是少之而又少了。所以把它嵌入到程序中，其实这样做是简单化了数据库开发的过程。嵌入式SQL的的确确是在POWERBUILDER存在，POWERBUILDER是有名气的4GL数据库开发工具，嵌入式SQL比一般SQL能做的东西都要强大，为什么还要否定它？我说你根本不知道什么是嵌入式SQL，你只会使用一般标准的SQL。
大家知道不知道，SQL重用一般都体现在计算和分析的时候，那个时候重用就比较有意义了。你知道不知道为什么ACCESS开发数据库都比其它的开发工具快N个倍，就是因为：
1、 本身的易学易用性，中文帮助提示。
2、 我所说的强大的嵌入式SQL功能。SQL分割功能。
3、 窗体、报表、和ACCESS内置的函数都是为数据库而设的。我可以和你打赌，做DELPHI和ACCESS的能力范围的交集的项目，你用DELPHI一个月做好的项目，
我可以用一个星期，或者短短的三天就OK。
你只会咬文嚼字。我不是专职的开发人员，写“玩”也不表示什么的。而且我说的话也不是什么幼稚的话，大家有空可以到到.www.access-cn.com看看，www.accessoft.com看看，看看ACCESS尽管不太优秀，但也有一席之地。
易学易用是原因之一，另一个更重要的原因是，它是4GL的数据库开发工具。
我可以和你打赌，做DELPHI和ACCESS的能力范围的交集的项目，你用DELPHI一个月做好的项目，
我可以用一个星期，或者短短的三天就OK。
第一：Access就比不过MS SQL Server...等其它大中型数据库系统，其实论能力还比不过MS自家的Visual FoxPro，楼主也一定没有用过Windows3.2时代的Borland Visual DBase！！有机会你找找用用，你感觉Borland Visual DBase比Access的可视能力与数据处理能力差多少？再次比你说的什么SQL：Access提供的SQL支持与业界的SQL标准不同...与MS自家的MSSQL就有一些不同，Access提供的SQL能比Oracle的还好？能力还强？？？所以
第二：Access提供不标准的SQL，也没有提供Oracle/SyBase/MSSQL/InterBase/MySQL等强大的数据管理与数据事件处理能机制，而Delphi是一个开发工具，可以连接以上所有数据库包括Access提供的解决方案，为用户定制各种类型分布式数据库应用
"我有理由说要比DELPHI说好 "<---这句话是有语病，但只不过是后面多打了一个“说”字。
VFP在作数据，绝对比ACCESS来得快
楼主对现在的数据库软件认识多少？
DELPHI强在编写大多数软件它都能胜认
POWERBUILDER强在专业的数据窗处理。
VFP强在语言很灵活，对表的操作很方便。
ACCESS我看到的它仅是数据库，拿它来开发？几个报表几个窗口，自己看看数据，单机版的有什么意义？
可以封装为WebService做所有平台下可处理WebService的语言和工具进行处理 ----- Access可以吗？
Delphi可以把相近的数据处理封装为组件、类等进行代码重用 ------- Access可以吗？
..........
太多了，楼主可能要说...“我说的是在Access可能的范围内比！！”对于这个可能的范围，那就是我们做开发的不懈做的应用，所以就用VC写了个Access叫你们这种人来做 hehe^^ 我们吃肉总要给你留点汤吧.........
－－－不是VB作不到，而是Access不支持View，如果用VB连接的数据库是MS SQL（其他不要说，估计你没有见过）,谁说不能这样：
在MS SQL中建立视图qry1:
create view qry1 as select a,b from table1
在Delphi和VB的任何地方都可以这样用：
select a,b*2 as n from qry1
2、这种SQL拆分，使调试和编写SQL难度减少了很多。而且又使大型项目的SQL重用变为可能。所以我做数据库到现在，也不把精力放在SQL的语法上，做SQL，也只是用心的在设计视图做和分析要求解的问题，对于SQL的语法，我不在乎，在必要时，才看看帮助。在网上看到这么多网友问这个SQL为什么错了，那个SQL不能执行，我心里就好笑，有了ACCESS，还有必要这样问吗？简直就是在浪费时间。
－－－大型项目的SQL重用？你到底有没有搞过大型项目。
－－－如果你认为用Access的那几招，就可以不懂SQL地搞掂数据库应用，那你未免太那个了。
楼主发的这个帖子提出的问题，根本不是孰优孰劣的问题，而是适用性的问题！
请问：你和网球冠军比乒乓球，和乒乓球冠军比网球，有可比性么？Delphi是开发语言，Access是一种桌面版的小型数据库。两个适用范围有很大不同的开发工具，怎么去比哪个好哪个不好呢？Access的确有易学易用性，它力所能及的仅仅是小型数据库应用领域（在中型数据库，百万级别的记录库表上，可能都得打个问号），Delphi也能兼容这个领域，但由于它不是Delphi的主要适用领域，所以易学易用性上的确差于它（从某种角度来说，仅仅在这里它们有一定的可比性）；Delphi则不同，它的应用领域远远不止Access所能及的那么一点，作为软件开发工具，我这里大家都很清楚Delphi的适用面有多么广，不需我多言了。我的意思是：二者是适用于不同开发领域、不同开发环境和不同开发要求下的两种截然不同的开发工具，它们的存在都有各自的理由，而没有谁好谁差的问题；所以选择用谁去完成您的工作仅仅依赖于实际项目，而根本没有必要去区分它们的高下！
大家不要说啦 ！！其实就是我们这些搞开发的不想再做小应用、桌面开发 所以就用VC呀Delphi什么的做了个Access，叫楼主这样的普通人玩的东东 嘿嘿~~
access的确是和delphi没的比的，不是一个等级上的东西
偶尔搞一些小东西玩玩，我就见过这样的人用Access编程序，不过也只能是玩玩而已！
access是什么吗?