但是当我注意到使数据具有移动性和Web性需要付出多大努力时，我开始怀疑那些厂商所宣传的---就连菜鸟也能通过点击几下鼠标就可以编写一个web化的事务处理系统---的目标到底需要多久才能实现。是的，如今确实出现了一些这样开发出来的程序，尤其是涉及业务处理的程序。但是要想那些非IT人员都能够通过简单的鼠标点击拖拽就能够编写出能和专业IT人员编写的程序相媲美的程序，则还需要事先完成很多工作。
挑战：这些事先所要完成的工作并不能通过简单的点击拖拽操作完成。
而不同的项目所需的努力程度也不尽相同。比如一个不带有历史遗留问题的全新项目，所要付出的代价比带有历史遗留问题的项目少很多。尽管如此，将各个部分结合起来也不是仅靠一个鼠标就能做到的，有时甚至让某个组件能正常工作都是一个挑战。
很多企业都具有遗留系统。不论他们想将系统Web化、移动化还是采用别的什么方法改进系统，跨越新旧系统间的差距，将其融合在一起所付出的努力要比开始一个全新的项目困难得多。一旦到了不得不改变的地步，成本将会大大增加。Web服务技术的高手会告诉你“如果你的Web服务是基于XML的，那么改变起来相对要容易很多，成本也会降低。”而Web服务都支持这种“由集成标准带来的成本降低”。不幸的是，很多时候并不只有标准问题，这里还涉及到哪个组件属于Web服务，哪些组件不是Web服务，以及该如何处理它们。虽然前景美好，但我们只能用旧有设备(不是鼠标)来实现向未来转变的目的。
一个可以解决问题的方法(虽然可能不太实用)，就是从同一个供应商那里购买全部产品。这当然会让一切都运行的很好。
在我的项目中，我使用VBA将邮件处理功能集成到Outlook 2003中。这个项目的目标很简单：读取邮件后，会以一种比较公式化语言来回复邮件。当我发现Outlook具有可编程特点后，我就开始使用这个功能了。过了几天，我在以前处理20-30封邮件的时间已经可以处理上百封邮件了。而且我还将包括邮件在内的很多数据存入了Microsoft Access数据库中。
不久后，这些数据库中的看似多余的数据发挥出了它的价值。比如我可以快速找到与某个公司对应的联系人员。现在很多厂商都依靠公关公司与媒体接洽，通过我的系统，我可以方便的查看哪个PR公司是为哪家厂商服务的，以及PR公司里的某个人员具体负责哪家公司。如果我需要找到某个读者的信息，也可以通过简单的数据查询来找到相应的信息，比如查找我联系过的对Java有兴趣的读者。
这套系统不但可以完成所有我希望完成的功能，还能完成别人的需求。当我将这套系统展示给别人看时，他们都说“我也需要这套系统，什么时候我能有这套系统。”从功能上说，我的系统相当完备。但从技术角度上说，如果允许多用户使用我的程序，我还需加以改进。另外，除了我的项目，肯定很多人也有类似的项目。开始的时候项目也许很小，但当其他人看到这个项目可以大大提高工作效率后，项目就有改进的需求了。让我们将数据查询扩展到企业局域网或者互联网上。让我们可以使数据库多用户进行更新，包括企业网外的用户。让我们可以在路上也能访问系统….另外，我们可以让数据和软件自动分发。
这样，最开始只是为了通过少量的脚本来沟通Microsoft Outlook 和Access，不但可以适合我，更可以适合其它用户。
在数据库方面，Access是我唯一的遗留问题(VBA是另一个遗留问题，将被VB.NET取代)。Access虽然简单，但对于我这种企业级的应用项目来说有些马力不足。而我的优势是不用担心其它的合作标准，我可以标准化一个企业的数据库技术，以便保证数据和中央数据服务器(采用Web接口或Web服务器)的同步，以及与移动或固定设备(笔记本、手机、台式机)同步。
大部分数据库公司都提供多种表格以便与其它数据库同步。比如iAnywhere(Sybase的一个部门)的MobiLink数据库同步技术，带有厂商提供的脚本，采用Adaptive Server Anywhere (ASA)实现桌面或手机设备与Oracle、IBM、以及 Microsoft的数据库同步。
由于iAnyWhere的数据库技术在移动解决方案方面的强度和成熟性，我偏向于在客户端使用这种技术。iAnyWhere的移动数据库服务器(ASA以及一小部分UltraLight)，可以用在PocketPC 以及PalmOS上，并支持存储过程以及触发机制(仅ASA)，并可以同步客户/服务器结构，通过基于Web的开发而不是基于应用程序的开发，为企业提供数据同步和移动访问能力(利用iAnyWhere的 AvantGo技术)。
针对中央服务器，我本来打算选择IBM、 Oracle或者 Microsoft的数据库作为中央数据存储，而采用ASA的客户端设备。但是当我阅读了iAnywhere的技术文档后发现，在采用ASA的情况下，不论是手持设备、工作站还是服务器，都没有很好的同步解决方案。同样，我也排除了Microsoft的SQL Server，因为我觉得这有些大材小用。ASA可以用于各种操作系统，在我的Red Hat Linux 9(Pentium II 处理器，192 MB内存)系统中，它可以流畅的运行。当然，如果我采用了它，下一步就是如何获取更大的效益。
在选择数据库时，我很担心自己会将Access抛弃，因为这意味着我将要迁移旧有的数据，同时还必须改写代码以适应新的数据库。虽然现在我已经把这两方面事情都办妥了，但并没有我想象的那么简单。
在其他数据库供应商中，Sybase提供了相应的升级工具用来从MS-Access迁移到iAnyWhere的ASA或ASA的高端—Sybase的 Adaptive Server Enterprise。我遇到的第一个问题是该升级工具并不支持Access 2003。因此我的工作不得不停止下来。直到Sybase的升级工具支持了Access 2003，我才重新开始了自己的项目。这个新的升级工具不但可以将Access中的表格和数据导入ASA，还可以将Access中的指针指向ASA的数据库，而不仅仅是转换基于JET的表格(Access 使用的是JET引擎数据库)。升级工具还可以复制基于JET的数据库，并将其重新命名，一旦升级后的数据库无法正常工作，用户可以方便的恢复基于Access的数据库。
在我看来，Access比很多数据库服务器都具有更好的兼容性，尤其是在设计表格、指定主键和目录以及生成关联方面。而Sybase提供的升级工具不但不支持我设计的表格，还不兼容某些数据。尽管如此，但由于它的升级效果，我还是很乐意使用它来处理我的数据库。
Sybase公布的另一个问题是目前升级工具还只能导入数据表格，而不能导入查询(ASA中将查询称为“view”)。查询的魅力在于，对于一个应用程序来说，查询实际上就像一个数据表。与在代码上处理数据表关系不同，有了处理查询，就可以不通过复杂的关系与外部代码或应用程序。比如，我的某些下拉菜单是受查询控制的，而不是靠数据表本身。你可以想象我的VBA代码是如何工作的---采用Microsoft ADO接口访问数据库，查找不存在的查询(通过升级工具升级后)。因此，我不得不通过Sybase Central程序手动重新建立查询。
重建查询后，我重新运行应用程序。结果VBA的debugger弹出了一个以前从未出现过的错误，从错误解释看，是Visual Basic方法(recordset.update)将一个永久错误数据载入了记录中。至于到底是哪里错了，我也不是很清楚。为了能在VBA环境外重建这个错误情况，我又在Sybase Central中使用一系列SQL语句试图进行同样的升级，但却没有出现任何错误。因此，我又回到应用程序中，将采用VB内建的建立、更新以及提交方法屏蔽掉，并采用SQL语句代替，来观察每一行代码的运行结果。
结果错误又出现了。
实际上SQL高手都知道问题出在哪里：当用SQL语句建立了一个新的记录后，必须运行另一个SQL命令(@@IDENTITY)，然后才能让新建立的纪录自动产生记录号。而VB并不需要这个额外的步骤。幸好Sybase的技术支持给我提供了一些与VB功能相似的代码范例，让我可以成功地解决这个问题。但是现在，我需要面对的是将全部代码都进行类似的修改，这令我有一种喜忧参半的感觉。一方面，我真的不想重新改写全部的代码;另一方面，在改写SQL代码时又让我想到是否有可能使用别的编程语言来提高程序的可移植性。比如，采用微软的C#(我比较不想尝试)或Java(如果我想将程序推向非Windows平台时)。
ASA与我的VB代码间的抵触使我确实为难了一阵。我向Sybase的技术支持人员询问有关问题，但他们明确的告诉我，从现有的信息看，ASA不兼容我的代码唯一的原因就是我的代码不符合SQL的ANSI标准。技术人员建议我在使用ASA处理数据记录时关掉ANSI兼容性。这个建议非常有用。不过我仍然趋向于使用自己的SQL语句。
当我作完这一切时，仍然没有进入设想的同步阶段。我甚至还没有对这个独立的单用户程序进行多用户化、web化、Web服务化以及移动化改造的解决方案。不管怎样，我还算是在正确的道路上，因为我对程序的这种改变绝对是值得的。
在这期间，我的门上一直贴着一张字条，写着“这不是一个仅靠点击拖拽就可以实现的编程区域，菜鸟勿进。”
文章来源于领测软件测试网 https://www.ltesting.net/
