大家都在谈商业版!
可我的旧版本项目文件一下子升不上来。
检查发现很多不能正常运行的地方，正一个个地消灭!
经验：如果用外部数据源，那最好不要用表达式列，因为：
表达式列不能参与SQL查询、
用表达式从子表统计数据则不能取消关联(也就是说不能灵活设置关联)、
表达式列中的数据也很重要的不能保存这不太好吧!......
没办法，要升的地方太多了，只有将系统日期改到两个月前，运行旧的版本先应急!
[此贴子已经被作者于2009-4-2 23:31:27编辑过]
表达式列如果用公式生成，加载数据时即时计算。
如果用sql查询，可直接在sql语句中生成表达式列的计算结果。
以下是引用wcs在2009-4-2 23:29:00的发言：
经验：如果用外部数据源，那最好不要用表达式列，因为：
表达式列不能参与SQL查询、
用表达式从子表统计数据则不能取消关联(也就是说不能灵活设置关联)、
表达式列中的数据也很重要的不能保存这不太好吧!......
个人感觉目前软件中的表达式列已经成为鸡胁！原因很多，以前讨论过，就不再详述了。无论是电子表格软件还是数据库软件，从来没有与狐表的表达式列类似的的功能，应该说表达式列是贺老师的创新和发明，但截止目前，我认为它是失败的！我预测:表达式列在未来的版本中只有两条路可走:一、取消表达式列，或者让表达式列作为数据列的一个类型；二、对目前的表达式列作出重大改进调整，扩充它的函数及计算功能、改进它的保存方式、提高它的方便性。
或许我的断言下得有点早，但对与不对，让市场、让更多的用户去评判吧！时间会证明一切的！
[此贴子已经被作者于2009-4-3 8:10:43编辑过]
以下是引用czy在2009-4-3 0:19:00的发言：
表达式列如果用公式生成，加载数据时即时计算。
如果用sql查询，可直接在sql语句中生成表达式列的计算结果。
表达式列可以达到的功能，用事件编程也可以达到的，而且用事件编程可以定位到具体发生变化的那个记录，这样效率是比较高的，不是从到到尾地计算。你想想，人家电信公司的数据库该是大吧，数据该是多吧，速度为什么那么快，我想无非是分散了计算的量，每次事件都即时计算的，不会重算整列更不会重算整表！
在sql中生成表达式列查询，我只会用简单一些的，复杂一点的比如有判断条件的，试了几回搞不定。
如果我的SQL很高明，那么狐表里面的“数据统计”和“交换数据”部分可以不看了，SQL不知要强多少倍！
呵呵，有相当部分的计算是比较简单的，无非是列于列之间的加减乘除，以及子表的统计，用表达式很好，表达式只是针对已经加载的数据，结果是瞬间出来的，不用担心效率问题。
如果需要后台也保留计算结果，自然是不能用表达式列的，因为表达式是临时性的。
用SQL语句虽然也能计算，但是有一个问题无法解决，数据一旦加载，结果无法自动更新，例如你修改单价，金额不会自动计算。
foxtable的交叉统计和分组统计是针对已经加载的数据，而且易用性不是SQL能比的。
1、后台需要保存计算结果，或者表达式无法计算的，自然用事件解决
2、简单的临时的计算，自然是表达式好，而且能让不会编程也不想编程的人，也能进行计算。
3、集中处理和统计大量的数据，例如上百万，自然是SQL好。
各取所需，谁也替代不了谁，表达示列不是我原创的，.net的DataTable本来就有的。
表达式列虽受限于聚合函数，目前无改进的可能，但我想它绝不会取消，因为狐表针对的用户应用面不同，需求自然不同，写软件和我们写应用系统有很大的区别，做应用系统可以只考虑自己用到的功能，写软件则要考虑很全面，要考虑到各个层次，使用习惯。易表够简单吧，就是这么简单的软件，只在其中做一些加减乘除的人都大有人在，所以我认为需要这种功能的肯定人大有人在。
就如楼上各位所言，sql够强大，为什么我们不去很好的用它的，就因为她太深奥了，一般人怕触及。
一个软件应尽量保存简易的方法，去繁从简才是正道。
个人认为43楼断言是早了点，而且太绝对，其实路并非只有两条。
随便提一下建议：狐表要是能提供跨表的统计功能就太好了。
比如，生成跨表的查询结果，狐表可以模拟一下SQL查询中一些跨表查询的功能，将它们设计成像分组统计一样（加个关联嘛），那就太好了。
老大可以设置简易一些的要，类似现在的统计窗口一样
如果太复杂了不好搞，可以只准许三层的关联引用，一般用户只有这么复杂的。再多，自已可以多搞几次这样的查询一样可以出来的。
[此贴子已经被作者于2009-4-3 10:35:37编辑过]