其实很多东西都是这样，不尝试，永远都不知道怎么回事。话说写程序的人，本来应保有好奇心，但我在这里所见到的，很多居然是宁愿保守的，比如抱着xp不放，连Win7都不肯尝试，老是担心这不兼容、那不兼容，但你都不安装了去试一试，光说有什么用，听别人说，人家也是乱说，你也乱信而已。搞开发，尤其要喜新厌旧，毕竟技术日新月异，新的版本推出，必然有修正旧版本毛病的问题，修补已知的漏洞，而那些解决方案，可能是以废弃某些手段为结果，那么必然或多或少地不兼容，循序渐进地跟进版本的更新，变动也是逐步的，了解新版本何以如此也意味着明白旧版本的问题所在，这同样是修正过去旧程序模式弊端的过程，不是跟风那么简单。像vfp6到vfp9，语言和数据库的结构、机制都有若干调整，为了看旧书本教导的代码和手段而宁愿保守vfp6不用vfp9的人，在这里所在多有。

大多数时候，被“不兼容”卡住的，绝大多数是不了解原有技术和原理导致的问题。一个软件，若是同一开发者推出的更新版本，必然考虑了原有技术的迭代问题，原来怎样做的，在新的版本下应以怎样的方式取代和迁移，都有考虑，绝不可能没有解决方案，否则那是另外一个全新的软件，而不是新版本了。每一次更新，都如此迭代一部分，你跟着更新，变动也小，但若长期保留在旧版本上，要你跳几个版本升级，那么所带来的变化当然比逐级变化大，甚至真有完全隔绝的可能，但由于你不知道每一版本的取代手段是什么，那么如此跳跃就更不知道该怎么接续了。

做IT的，没有好奇心，别入这一行。这是很多业内前辈教导过的话。

技术的选择，无非是两个基本点：一是需求的定位，二是自己的风格。了解所选用平台和工具的性质，是最起码的。像vfp这个工具，脱胎于FoxPro，属于文件系统数据库，是基于F/S架构的，其最大的特性，是对文件系统进行操作，效能体现在文件系统上，它以各种高速读写磁盘文件的技术为基础，不是针对依赖网络线路的远程数据存取技术，它的数据库物理组织结构在磁盘文件，若无法在磁盘上读写文件，则其高速技术就无法发挥，那就不是vfp了。vfp本身就是数据库系统，也是罕有的包含内置编程语言的数据库（SQL Server的存储过程是库内局部语言，用于处理有限范围的数据，与vfp全面性管理的语言是根本不同的），它不需要使用别的数据库，但现在的大多数人，却恰恰是弃vfp的长项数据库不用，转而使用第三方数据库（SQL Server、Access之类），而把vfp仅仅作为UI语言使用，那根本就不是在用vfp。论写UI，C#比vfp更好，也与现代操作系统的接口更融洽。

基于SQL Server构建的数据库系统，向网络端口发送一条写有SQL命令的字符串就可以了，用任何语言都可以做这种事，不需要vfp。凡是用这种方式的，都不属于vfp编程范围，但现在七成左右的讨论都是这种。

承蒙TonyDeng版主教导，在这个论坛多次得到大侠的指导，大侠是否还记得：一年前，我遇到一个FTP下载的问题，大侠花了近半天时间指导我，还把自己的代码发给我。这些都是我不能忘记了。

那么，我下定决心了，在我的软件开发完后，购买SQL2008数据库。至于可能存在的兼容性问题，正如版主所说，可以慢慢迭代。

不过，有一点学生有疑问，版主说道：“它(VFP)不需要使用别的数据库，但现在的大多数人，却恰恰是弃vfp的长项数据库不用，转而使用第三方数据库（SQL Server、Access之类），而把vfp仅仅作为UI语言使用，那根本就不是在用vfp。”

第一：VFP的数据库是基于单机的，如果是基于网络的应用，那么VFP的数据库就力不从心了。而mssql/mysql这些数据库则能够轻松应对。

第二：DBF时常出现的坏表情况确实让人崩溃。

我现在主要采用VFP + SQL的方式，用VFP做UI，虽然这不是VFP的强项，但我是业余选手，使用VFP完全是个人兴趣，其他语言我也不会，MSSQL作为后台数据库，用VFP内存表对数据进行加工（这是否也算使用了VFP的强项？？）。确实解决了网络版应用 + 坏表问题。

看版主回答的问题，不光是从技术上进行指导，更主要是从思想上加以引导，版主不像搞技术，更像一个思想家。

另外一个问题请教版主：

您提倡的那种纯程序方式开发应用，与拖控件的方式想比，有哪些优势？

这是不是与可视化编辑的理念有悖？因为两者的结果都是一样的，而且后者更直观。

我提到这个问题纯属好奇，无知之处，还请版主勿怪。

我前面说了，vfp是基于文件系统的数据库，倚靠各种缓存技术进行高速读写，这与远程数据库服务器的形式不一样，后者不是基于文件的。dbf文件的损坏，主要出于缓存失效破坏的文件结构，很多是编程不正常使用缓冲机制造成的。vfp是F/S的网络架构，对文件服务器以文件目录的方式读写，不像SQL Server等是接收指令做动作然后返回数据集，vfp是自己直接对服务器上的文件系统进行操作，此时速度受限于网路速度和带宽，前者的负荷在服务器本机上，配置与承受的并发数成正比关系，vfp不需要在服务器上部署数据库系统，祗作文件储存器使用，可说是分布式的。

把vfp单纯作UI语言使用，亦未尝不可，祗不过别要求太高罢了，很多酷炫的功能，它实现不了，或者即使能实现，也要付出很大的精力。比如像你说的，在任务栏上的菜单，那不是它的强项，它本来设计也不打算拥有那样的功能，毕竟已经停止开发那么多年，不可能储备那些潜力。

“可视化”，是指做出来的效果可以直观地看见，不是设计时拖拉控件。比如html的开发，它是写代码的，但编辑器可以即时切换到效果界面，马上看到效果，就是可视的。代码编程的优点，是自己很清楚自己在干什么，而拖拉方式，很多时候使用者是不知道那功能的细节是怎么实现的，一旦有细微的变化需求，就无从入手。另外，编程中很多时候是动态生成的，比如某个Grid，你可能无法事先确定显示哪些字段，就不可能用拖拉式设计做出，祗能写代码。写代码，可以反回头拖拉；只懂拖拉，却无法写代码。拖拉法属于碎片式编程方式，代码东一块西一块，对于不是自己一手一脚做出来的程序，别人要看懂和维护它，需要付出不必要的精力（实际上有效动态生成的画面，你看设计窗体是没用的，最终还是看代码）。

版主说得有道理。

但拖拉基本控件的方式可以快速构建用户界面，比如：我拖拉一个Grid到表单上，然后用代码定义它的外观，动态生成要显示的内容，决定它的行为，其实每一步我自己都很清楚，这样不是很好吗？

况且，完全用程序来构建的方式，其实多数时候使用的依然是VFP的基本控件，对于基本控件的内部依然很少能够干预。

我同样可以使用类设计器，来改进基本控件，或者说设计出自己的控件。

[ 本帖最后由 eepcvfp 于 2015-8-16 21:26 编辑 ]

好像我听说：完全用程序的方式来构建应用，在操作系统分配内存时要占有优势，是不是这样呢？

[ 本帖最后由 eepcvfp 于 2015-8-16 21:38 编辑 ]