解决分页“奇怪”问题

在使用“XDOWNPAGE分布类”的时候,有时候总页数会莫名其妙多一页。详见:一个奇怪的分页问题--关于'XDOWNPAGE ASP版本'版本 1.00

 

先说解决方法:

 

 

将下列代码

  1. If int_totalRecord mod PageSize =0 Then
  2.  int_TotalPage = CLng(int_TotalRecord / XD_PageSize * -1)*-1
  3. Else
  4.  int_TotalPage = CLng(int_TotalRecord / XD_PageSize * -1)*-1+1
  5. End If

修改为

  1. If int_totalRecord mod PageSize =0 Then
  2.  int_TotalPage = fix(int_TotalRecord / XD_PageSize)
  3. Else
  4.  int_TotalPage = fix(int_TotalRecord / XD_PageSize)+1
  5. End If

分析clng:

 

CLng 函数可把表达式转换为长整形(Long)类型。


注释:值必须是介于 -2147483648 与 2147483647 之间的数字。

注释:CLng 不同于 Fix 和 Int 函数删除小数部分, 而是采用四舍五入的方式。 当小数部分正好等于 0.5 时, CLng 函数总是将其四舍五入为最接近该数的偶数。如, 0.5 四舍五入为 0, 以及 1.5 四舍五入为 2 。

 

dim a,b
a=23524.45
b=23525.55
document.write(CLng(a))
document.write(CLng(b))

 

得出结果为

23524
23526

 

这就造成总页数有时候会对,有时候多了一页。

 

int函数会有可能溢出,故于此,我用fix函数。

 

狂汗。。。。。。 在《一个奇怪的分页问题》的回复中,有个兄弟已经指出问题所在了, 我居然没看到。只是没说得更明白一些而已。

SQL分页指令中包含了ORDER BY排序指令,可以按照指定的排序方式对数据进行排序。但是在某些情况下,我们会发现很奇怪的事情:ORDER BY排序指令失效了。下面详细介绍一些可能导致SQL分页ORDER BY失效的原因和解决方案。 原因一:使用关联查询 一些情况下,我们需要使用关联查询,这种情况下,如果没有正确指定ORDER BY排序方式,分页查询结果可能会不正确。这是由于关联查询时,可能会发生复杂的排序,使得原本按照单个字段排序的结果失效。 解决方案一:在分页指令中正确指定排序方式 在使用分页查询指令时,需要指定排序方式,以确保结果正确。通常情况下,我们可以按照某个字段进行排序,再进行分页查询。 原因二:查询条件过多 有些情况下,我们在查询时可能会指定过多的查询条件,这可能会导致SQL查询优化器无法正确地优化查询,进而导致ORDER BY排序失效。 解决方案二:优化查询条件 优化查询条件是解决此类问题的关键。我们需要明确具体的查询需求,在查询时尽量使用简洁的条件和正确的指令,以减少SQL优化器的工作量。 原因三:服务器负载过高 在某些情况下,服务器负载过高可能会导致SQL分页ORDER BY排序失效。当服务器负载较高时,可能会影响SQL查询引擎的响应速度,使得查询的返回结果不正确,包括ORDER BY排序失效。 解决方案三:优化服务器负载 为了避免服务器负载过高导致的ORDER BY排序失效问题,我们需要优化服务器的性能。可以使用多台服务器进行负载均衡,调节服务器计算资源的使用,以提高服务器的效率。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值