以下是备注：
1. 建立Creat.bat命令其实就是用windows记事本输入md命令，如Md  D：\\backup，保存后修改后缀名为bat
2. 先创建一个变量，表验证公式中的命令是sendkeys（~）和msgbox（“”，0），原理是如果这个变量的值为**的时候则关闭，否则显示提示并立即确定，用户看不见这个提示出现和关闭的过程；就达到了不能使用叉叉关闭和出现提示对话框的目的(如果出现了是否保存的对话框用户就可以乘机保存了)。需要注意的是如果用户在windows打开了很多任务并且来回切换，sendkeys可能会“找错”对象，因此最好在msgbox中写入“请使用按钮退出”的提示，一旦sendkeys失效，用户也能看到正确的提示而不是一个空的对话框知道如何关闭系统。
3. 此处预处理公式的目的是判断专用的文件夹是否存在，存在则什么都不做，如不存在则打开bat命令创建文件夹，backupfile不是目的，而是一个判断文件夹是否存在的手段，我也找了很久，易表好像只能判断文件是否存在不能判断文件夹是否存在，而且IF只能对backupfile是否成功作出判断，不能对exportdbfile是否成功作出判断，因此不得以，让备份文件担任判断的key了！还需要指出的是，openlink和backupfile不能连续执行，否则只能创建文件夹不能创建备份，因此我在他们中间加了msgbox，而且是返回true值，用户点击确认后立即备份，这样就达到了用户首次打开系统时自动生成备份文件夹和生成系统判断这个文件夹是否存在的key文件的目的，而且如果用户删除了这个文件夹或移动了文件夹，系统都会自动创建，需要注意的是如果移动或删除了文件夹，加载数据将会失败，因此正好可以在msgbox中提醒用户不要操作这个文件夹！同时，首次备份的文件也是系统交给用户时生成的“处女”备份，可以在创建这个备份时以生僻的字母作后缀名，用户无法打开，达到灾难备份时调用恢复的效果（有点拗口，但是请仔细阅读，我是反复测试的）
4. 在这里我需要说明的是，a.导出成excel数据时不能任意指定后缀名，而且如果表中有类似身份证号码之类的数据导出后excel会采用科学计数法保存，那么在加载数据的时候身份证号码就“走形”了；前辈有用eval对身份证号码列进行处理后导出数据的精典范例，这样可以使导出的excel文件身份证号码正确，感谢这样好的方法，不过在加载数据时，合并数据的时候列就错位了！因此导出数据时不能对身份证列进行如上处理，否则加载将失败！这个是excel的弊端，所以我建议可以生成access格式，不过我没有测试；b.导出数据在不保存当前文件的情况下可以顺利执行！所以无需真正地保存当前易表的系统文件后再导出数据！c.另外一个需要注意的问题就是导出前一定要显示所有列，否则导出时仅仅导出了显示的列中的数据！那样的话部分数据将会丢失！！导入的时候则没有关系了，什么视图都可以；
5. 专用的退出按钮也要结合预设的变量，即向变量写入文件验证符合的内容后，清除所有修改标记，执行退出，那样的话就不保存当前文件退出了。
6. 文件验证公式中增加的内容是合并预先生成的excel数据文件，需要提醒的是如果系统中有统计表，那么统计表就无需导出，只需要将必要的数据导出即可，加载数据后立即刷新所有表，那么上次用户“存盘”的数据都可以显示并且在统计表中进行统计。这样做可以减少导出和加载的数据量缩短预处理公式的执行时间。而且为了追求完美，最好在加载前对文件夹的excel文件是否存在进行判断，存在就加载，否则提示用户找不到数据文件，可能是被删除或修改了。另外还有的就是，易表默认空表有一行空行，因此加载完成后应该删除第一行；

最后是易行天下对以上做法利弊的自我评价，也请斑竹们斧正：
优点1. 从整个过程我们都可以看到，易表的文件仅仅是一个“数据编辑分析器”，从来执行过没有真正意义上的存盘，这样的话文件始终都是一个“处女文件”，不会因为反复保存而增大；
优点2. 易表存盘的速度不是很快，数据量大的时候尤为明显，但是导出数据的速度和合并数据的速度还是比较理想的，因此可以让用户存盘的速度得到提高我在测试中300行80列的数据导出用时1秒，比存盘快；打开的速度也应该得到提高！！（我的文件以前经过1年的编辑打开都要5秒）；而且很多专用软件打开时需要初始化然后加载数据然后更新等等，也消耗了用户不少时间，但是用户感觉这是专业的表现，既然如此我们也可以做到，通过状态条显示以上过程对于易表来说是易如反掌的事情；
优点3. 达到了程序和数据分离的最终目的了，以后大家上传文件里面都没有数据，岂不快哉？而且如果用户有修改程序的要求也不必担心数据泄露。
优点 4. 不必担心易表系统文件意外被锁或丢失、损坏造成数据丢失！这是一个比较具有实际意义的优点，一旦发生意外，用户使用备份的系统文件同样可以读取数据继续工作；这也是程序和数据分离的根本动机和出发点；

缺点 1. 这个方法对数据量超级大的用户不适用，看过一个论坛的文件，加载需要15分钟，这是不行的；
缺点 2. 系统的设计者需要多方位全盘考虑整个过程，为防止意外发生需要反复测试，确认安全后才能交付使用，否则会带来数据丢失的危险！因此设计上需要万分小心！
缺点 3. 不是缺点的缺点：真正的数据都在指定的文件夹里，一旦文件夹丢失，数据就没有了。

附加一个测试的方法建议：我前段时间上传了一个“公式超长巨无霸”，作用在于用基准数据对数据库的数据进行验证，大家可以制作具有用某一个基准表的来窗口验证数据是否正确，最好再作一个统计表，分别在导出前和加载后对数据库进行统计测试看结果是否相同。


-=-=-=- 以下内容由 易行天下 在 2007年01月19日 07:57am 时添加 -=-=-=-
由于很多系统都在网络环境下使用，因此易行天下经过再次测试，现更新以上发表的部分内容：
更新1：在导出数据时地址的路径不是d：data，而是docdir+"\\data"这样数据就导入到了系统所在的服务器文件夹中的data文件夹中！导入数据时也是一样。
更新2：导入时,imoprtdbfile是将文件合并至当前表，因此需要辅助执行opengrid（表1）后再importdbfile，并且是依次执行；为了不让用户看到，最好隐藏表的界面，弹出窗口，在窗口中告诉用户正在加载数据；执行完毕后再

假设如下：
如果A用户在A表里增加了一条新纪录并修改了一条老纪录，这时没有保存；
同时B用户也打开了A表没有做任何操作，
接着，A用户保存退出，结果应该是A表增加一条新纪录并修改了条老纪录；
这时，B用户也保存退出，那将出现戏剧性的结果，数据又被B用户恢复了，A表没有增加数据也没有修改数据。

不知道楼主明白我的意思没有，由于A、B用户无法同步更新数据，而数据导出又不能判断哪次操作是更新了数据，只是最简单的覆盖数据操作，那样是不行的。

我现在遇到与这位朋友同样的问题，不知道楼主有没有好的办法。