以下是引用czy在2009-2-23 23:10:00的发言:
老六,Dim dst as Table = dt 不行吗?
记得如果从临时表生成目录树已经支持了,如:e.Form.Controls("TreeView1").BuildDataTree(dt, "", "某列")
我原本也想这样...但不行啊....
唯有用QueryBuilder了....
以下是引用hnaysx在2009-2-23 23:25:00的发言:
其实本来就不要分这些东西就好了 别分DATATABLE 和TABLE
TAble仅仅作为一个一个表格控件
这样区分带来很大的灵活性,负作用是很多用户一时理解不了。
如果你深入,你就会发现分开的优势是大大的。
以下是引用狐狸爸爸在2009-2-23 23:30:00的发言:
这样区分带来很大的灵活性,负作用是很多用户一时理解不了。
如果你深入,你就会发现分开的优势是大大的。
老爹,借用一句广东话,我现在可是"一头雾水"啊.....
不过随着深入学习,隐隐感觉到这样区分是有必要的..
以下是引用菜鸟foxtable在2009-2-23 23:39:00的发言:
老爹,借用一句广东话,我现在可是"一头雾水"啊.....
不过随着深入学习,隐隐感觉到这样区分是有必要的..
多看几次帮助,多实验,不着急作系统。
我开发Foxtable前,至少看了半年的相关书籍,做了无数的实验,中途其他什么也不干。
当然foxtable要比专业的开发工具简单很多,但是开发篇的Foxtable编程这一部分,看个六七次也不算多。
以下是引用狐狸爸爸在2009-2-23 22:31:00的发言:
cmd.ExecuteReader()
生成的是临时DataTable。
如果你要可见的Table,用QueryBuilder/OuterTableBuilder,可以同时生成DataTable和Table
认真分析一下,好像还是有问题,我看帮助中的说明,用QueryBuilder/OuterTableBuilder都有一个很大的限制,就是只能接受SQL语言的查询语句(Select),而不能接受SQL的其他语句。但SQL command却可以接受任何的SQL语句,也可以执行一个SQL的存储过程,执行存储过程的时候还可以带参数。SQL command的灵活性和通用性是用QueryBuilder/OuterTableBuilder 无法可比的,或者说用QueryBuilder/OuterTableBuilder 根本代替不了SQL command。在正式的数据库编程的系统中,为了提高执行效率,往往都是开发语言代码+SQL存储过程的(而不是只用SQL的 select语句),所以在很多地方根本无法使用QueryBuilder/OuterTableBuilder,而只能使用SQL command,在实际中,可能需要见到或者使用SQL command生成的表,不知为什么贺老师把SQL command的ExecuteReader生成的Datable做成一个不可见的,为什么不能把它设计成生成一个可见的表,或者说同时生成DataTable 和Table呢?这不是故意给用户增添麻烦吗?实在令人费解!希望贺老师认真考虑这个问题!
[此贴子已经被作者于2009-2-24 9:17:06编辑过]
补充:另外问一下贺老师,虽然用SQL command的ExecuteReader生成的DAtaTable不可见,能否采取一个简单的变通方法来解决这个问题(我还没有试)?:
再定义一个DataTable,让它等于SQL command生成的不可见的DataTable,并让这个新定义的DataTable同时拥有Table,即变成可见的?
其实问题可以说得再简单一点:如果已有一个不可见的DataTable,系统应提供一个方法得到它的Table,让它可见!
[此贴子已经被作者于2009-2-24 9:27:53编辑过]
想了一下,终于找到了一个比较完满的解决办法,就是用DataList来实现DataTable的显示,因为只要有了DataTable,DataList就可以动态绑定它,而不管它有没有Table。鸡胁有时候也能办大事情,看起来DataList这个鸡胁还真的不敢轻易说抛弃啊!还望贺老师继续重视它,继续强化它的功能!
但使用DataList也有不便的地方,就是DataList只能显示,并不能编辑,所以,如果能让SQl Command 同时生成DataTable和Table,或者能提供一个方法根据不可见的DataTable生成可见的Table,就更方便了!
[此贴子已经被作者于2009-2-24 14:59:27编辑过]