Rss & SiteMap

Foxtable(狐表) http://www.foxtable.com

新一代数据库软件,完美融合Access、Foxpro、Excel、vb.net之优势,人人都能掌握的快速软件开发工具!
共4 条记录, 每页显示 10 条, 页签: [1]
[浏览完整版]

标题:关于FoxTable的列

1楼
ybtxdz 发表于:2008/10/3 17:51:00

 
终于,在试图导入一个有许多列的数据文件后,得到提示:“数据超过253,无法导入”。经过一番测试,发现FoxTable的一个表,其数据列最多不得超过254列。不知这个数字能不能得到突破:SQL的最大字段为1024;Execl2007的列已不再是2003的254列而是达到了16384列;而易表的一大亮点就是,多年前易表就具有了只要条件允许,可以增加的列是无限制的。经测试,易表同样可以达到16384列甚至比16384列更多的列。数据列的扩充,对于多列数据的管理犹为重要。
 

FoxTable设计了表达式列对表进行列的扩充,但是仅用少有的几个函数想进行较为复杂的表达式运算是几乎不可能的,而在表达式列里使用计算代码计算出来的结果却不能保存,下次打开文件,需要另花时间重算。这对多列数据的管理是一个不小的打击。从易表移植到FoxTable,如果涉及多列数据,那将会遇到这些问题而带来不少的麻烦。
 

期待FoxTable数据列的突破……
 

2楼
kylin 发表于:2008/10/4 16:00:00
没用到这么多列,太超过了吧。
呵呵。
3楼
狐狸爸爸 发表于:2008/10/6 9:25:00
关于列数,用外部表吧,例如sql server。
表达式列的计算结果是不需要保存的,因为打开之后,会即刻自动生成。
如果要能够保存的计算结果,用数据列加计算代码。

用计算代码计算的结果,如果不能保存,肯定是因为该列是表达式列造成的。
请参考:

数据无法保存?

在Foxtable的测试阶段,经常有人提问:为什么某些列的数据无法保存。
绝大多数时候,都市同一个原因造成的:这些列是表达式列,而表达式列的内容是不会保存的。
可是不少用户会反驳:我这个列不是表达式列,这一列没有设置表达式,列中的数据是我手工输入的啊。
其实判断谋列是否是表达式列,是不能用否设置了表达式或是否能输入内容来判断的,判断的原则很简单,只需选择该列,然后单击下面的按钮:



图片点击可在新窗口打开查看此主题相关图片如下:0037.gif
图片点击可在新窗口打开查看

如果该列能够设置表达式,说明该列就是表达式列,其内容肯定是不能保存的。
导致这种情况发生的原因是:在增加数据列的时候,本应该单击“数据列”命令,却误单击了“表达式列”按钮。

另一种不能保存的情况我只遇到过一次,原因更简单:用户将项目文件的属性设置成只读了。


4楼
cpayinyuan 发表于:2008/10/6 9:41:00
以下是引用狐狸爸爸在2008-10-6 9:25:00的发言:
关于列数,用外部表吧,例如sql server。
表达式列的计算结果是不需要保存的,因为打开之后,会即刻自动生成。
如果要能够保存的计算结果,用数据列加计算代码。

用计算代码计算的结果,如果不能保存,肯定是因为该列是表达式列造成的。
请参考:

数据无法保存?

在Foxtable的测试阶段,经常有人提问:为什么某些列的数据无法保存。
绝大多数时候,都市同一个原因造成的:这些列是表达式列,而表达式列的内容是不会保存的。
可是不少用户会反驳:我这个列不是表达式列,这一列没有设置表达式,列中的数据是我手工输入的啊。
其实判断谋列是否是表达式列,是不能用否设置了表达式或是否能输入内容来判断的,判断的原则很简单,只需选择该列,然后单击下面的按钮:



图片点击可在新窗口打开查看此主题相关图片如下:0037.gif
图片点击可在新窗口打开查看

如果该列能够设置表达式,说明该列就是表达式列,其内容肯定是不能保存的。
导致这种情况发生的原因是:在增加数据列的时候,本应该单击“数据列”命令,却误单击了“表达式列”按钮。

另一种不能保存的情况我只遇到过一次,原因更简单:用户将项目文件的属性设置成只读了。


贺老师,既然多个用户会把某个列是否是表达式列看错,说明"设计表"窗口有问题,建议在"设计表"窗口的列表中,加一个列,字段类型:即"数值列/表达式列".我在以前的建议中,已经提过关于对设计表窗口的改进问题(有多项),望您认真考虑!

共4 条记录, 每页显示 10 条, 页签: [1]

Copyright © 2000 - 2018 foxtable.com Tel: 4000-810-820 粤ICP备11091905号

Powered By Dvbbs Version 8.3.0
Processed in .02344 s, 2 queries.