表A 里存在一字段 adate 为date型,有数据,能与其他具体的时间进行比较select * from A where adate >to_date('19200101','yyyymmdd');但是在进行to_char转换时,出来的值有问题
select to_char(adate,'yyyymmdd') from A,出来的结果,有部分居然是'00000000',该条数据该字段是有值的。不知哪位达人知道原因,个人感觉应该是数据存在问题,但找不出出现这样问题的原因

解决方案 »

  1.   

    直接 select adate from a where to_char(adate,'yyyymmdd')='00000000' 执行看看出来的结果有没有不正常的数据
      

  2.   

    有的记录中的adate字段中有NULL值。楼主应该相信,计算机是没有错的,要错也是人让它出错。
      

  3.   

    直接 select adate from a where to_char(adate,'yyyymmdd')='00000000' 执行看看出来的结果有没有不正常的数据.
    肯定有吧.................
      

  4.   

    楼上几位说的可能都有问题。日期格式里应该不可能有0000年的,这样的数据是存不进数据库的。
    若日期字段等于NULL的话也不会出现8个0的情况。只会是个NULL,不管你用TO_DATE还是TO_CHAR转换。
    我测试的环境是10G 10.2.0.3.0
      

  5.   

    当然如果你用于存储日期的字段,其类型为字符型,那么8个0是可以存进数据库的。
    但你在TO_CHAR转换的时候会报错,提示数据有问题。所以我很想知道楼主到底是如何搞出这样神奇的事故的,非常崇拜!
      

  6.   

    select adate from a where to_char(adate,'yyyymmdd')='00000000' 
    这个显示出来的值是正确的,有值的,LS,可以排除NULL的情况,因为都是有值的
      

  7.   

    而且,这部分有问题的数据可以拿来和其他时间进行比较。select adate from a where to_char(adate,'yyyymmdd')='00000000'  and adate>to_date('20000101','yyyymmdd')这样都能查出来数据。费解,时分的费解
      

  8.   

    其实,这部分数据,是我女朋友在处理数据的时候发现了。我看过以后也觉得非常的奇怪,但还是未找到原因所在。该部分数据的来源应该是从某些地方导入的,具体采用什么格式导入不得而知。该批数据的日期,只要你在ORACLE环境下随便做个修改,就恢复正常了
      

  9.   

    哦你这么一说,我觉得很有可能是从EXCEL里导入的!
    当EXCEL里用于存储日期类型的单元格长度不够的时候默认会变成XXXXXXX这种样式!
      

  10.   

    to_char(adate,'yyyymmdd')--将变量adate转换为date型。
    adate>to_date('20000101','yyyymmdd') --与20000101这个时间比较。
      

  11.   


    這樣不會報錯嗎?
    ORA-01861: literal does not match format string