标题：目录树的问题建议及扩展

BuildDataTree是根据指定数据表的内容自动生成目录树节点。试用一下感觉非常方便，但真正把它用于项目开发时，我发现它有个很大的弊端。
先看一下它的生成方式：BuildDataTree(DataTableName, Filter, Column1, Column2, Column3...)
这就是说，BuildDataTree必须要根据指定的数据表才能生成，而这个表也必须是事先加载的。否则，目录树就无法生成。这在实际应用中会有很多不便，现以一个例子说明：
假如我使用的是外部数据源，想通过目录树对一个包含100万行的数据表、并按照“班级和姓名”进行查询。以目前的BuildDataTree方法，可以有2个解决方案：
1、常规方案：将该外部表全部加载，并按“班级、姓名”列生成目录树。
2、中转方案：在生成目录树之前，先根据该数据表生成一个只包含“班级、姓名”的临时表，目录树直接根据此表生成。
以上2种方案都有显而易见的不便之处：第1种方案是将100多万条的数据先加载、再生成目录树，这种方法想想都可怕；第2种方案则多了个临时表，有点啰嗦。因此，针对大容量数据的目录树生成问题，希望老六也能参考一下分组统计与交叉统计的做法，允许通过后台数据库直接生成。
由此还可以延伸一下：比如象来源于其它表的列表项目，这些来源表也都是要事先加载的，为什么就不能扩展到直接对后台数据库取值呢？我目前在用foxtable做一个项目的开发，凡是涉及到列表项目的，都要把来源表加载进来，实在是不习惯。数据库中所涉及的表基本上都要加载进来了，总觉得很啰嗦也很不简洁。

如果能在table之外，增加一个类似于Query的数据集就好了。该Query的功能与table相同，只不过它的来源方式很灵活，可以是后台数据库中的一个表，也可能是一个SQL语句返回的数据集合。如果有了Query，BuildDataTree时就可以直接写成：
BuildDataTree(Query, Column1, Column2, Column3...)，连filter都可以不要了。
目前不论什么都必须要以table的形式加载并进行物理存储，确实很不方便。

有两个语法：

BuildDataTree(DataTableName, Filter, Column1, Column2, Column3...)
BuildDataTree(DataTable, Filter, Column1, Column2, Column3...)

你可以直接用SQLCommand的ExcuteReader生成一个临时的DataTable，然后根据这个生成目录树。

呵呵，刚才仔细研究了一下ExecuteReader示例，似能实现我期待中的Query功能了。
谢谢老六！看来还要继续深入学习！！

问题已解决！