ACCESS毛病:试图实行的查询中不包括作为算计函数一部分的特定表达式的办理办法 ...

InnoDB数据表的索引,与InnoDB数据表相比，在InnoDB数据表上，索引对InnoDB数据表的重要性要大得多。在InnoDB数据表上，索引不仅会在搜索数据记录时发挥作用，还是数据行级锁定机制的苊、基础。明天在Access中查询表中最年夜值时，呈现了"试图实行的查询中不包括作为算计函数一部分的特定表达式"毛病，我的SQL语句以下：
selecttop10max(id)fromarticleorderbyiddesc

细心反省SQL语句，并未没有毛病，然后把该语句放进到SQLSERVER中实行，也能准确前往了局。真的很无法了，在网上搜刮办理办法，本来，在ACCESS中，假如语句中包括有聚合函数，那末语句select中除聚合函数列外，别的一切列必定要在groupby中。

改写查询语句：
selecttop10max(id)fromarticlegroupbyidorderbyiddesc

实行乐成.

假如伴侣看的够细心，大概你已看出了成绩，下面讲到的"假如语句中包括有聚合函数，那末语句select中除聚合函数列外，别的一切列必定要在groupby中"，而我的例句"selecttop10max(id)fromarticleorderbyiddesc"中并没有包含别的列，为何也要加groupby呢？经测试后发明，本来是由于我加了orderbyiddesc排序前提的缘故原由，假如不加该排序前提，语句"selecttop10max(id)fromArticle"也是能够实行乐成的。

一向都很罕用Access,如今才发明Access与SqlServer比起来还真贫苦。

附：在Access一样必要增加groupby的别的函数语句：
selectmin(id)fromarticlegroupbyidorderbyiddesc
selectcount(id)fromarticlegroupbyidorderbyiddesc
selectsum(id)fromarticlegroupbyidorderbyiddesc

等。mysql的prepare其实是本地PHP客户端模拟的，并没有根据你mysql的设置做字符集的调整。应该交与mysqlserver端做prepare，同时得调用mysql_set_character_set去操作，server才会按照字符集去做转义。

代替了原来VB式的错误判断。比Oracle高级不少。

微软对CLR作了大篇幅的宣传，这是因为数据库产品终于融入.net体系中。最开始我们也是狂喜，感觉对象数据库的一些概念可以实现了。

其实可以做一下类比，Oracle等数据库产品老早就支持了java编程，而且提供了java池参数作为用户配置接口。但是现在有哪些系统大批使用了java存储过程？！连Oracle自己的应用都不用为什么？！

但是随着数据量的增大，这种成本差距会逐渐减小，趋于相等。（500万数量级只相差10%左右）

这就引发了对varchar和char效率讨论的老问题。到底如何分配varchar的数据，是否会出现大规模的碎片？

可能有的朋友会抱怨集成的orderby，其实如果使用ranking函数,Orderby是少不了的。如果担心Orderby会影响效率，可以为orderby的字段建立聚集索引，查询计划会忽略orderby操作（因为本来就是排序的嘛）。

原理很简单，对要求长时间计算某一时间点的报表生成和防用户操作错误很有帮助。但是比起Oracle10g的闪回技术还是细粒度不够。可惜！

但换公司用MSSQL2K感觉自己好像根本就不了解MSSQL。什么DTS触发器以前根本没用过。