**********MSSQLSERVER，某表能读不能删,它怎么了？************

数据库是SQLSERVER，前台是PB，跟PB没有关系吧！？

解决方案 »

  1.   

    都一样，跟ODBC也没有关系，跟PB也没有关系，在查询分析器中试验也是这样...
      

  2.   

    关键是表在客户的机子上，我已经回到‘家’了，SQL的错误码现在是搞不到了！
      

  3.   

    检查如下项目：
    1、驱动程序对否？（客户可能安装别的软件替代了sql server的ODBC驱动）；
    2、有权限否？
      

  4.   

    您的ODBC连接用户没有Delete权限
      

  5.   

    to:supsuccess(口气不小)　
    你也太容易上火了！
    从你说的看，好象是索引或者数据的存储有些问题，现在你重建一表，是个不错的应急方法。
    以后遇到这个问题，可以用DBCC CHECKTABLE（YOURTABLENAME）来检查，有问题的话再用 DBCC CHECKDB 或者 DBCC CHECKALLOC 修复。你的情况还有一种可能是表被表极锁，你的情况可能不是。
      

  6.   

    同意楼上，重建索引试试DBCC DBREINDEX 
      

  7.   

    感谢Haiwer(海阔天空)和learnlj(共同走过)！
    我试试！
      

  8.   

    DBCC CHECKTABLE（TABLENAME）时：没有返回错误
    重建索引(DBCC DBREINDEX )时，报：
    Extent chain for object 180195692 is not correctly linked.
    怎么办？？
      

  9.   

    DBCC CHECKALLOC ('yourdbname',REPAIR_ALLOW_DATA_LOSS )
    进行修复！
      

  10.   

    我已经用过DBCC CHECKDB了，没有报错，还需要DBCC CHECKALLOC ('yourdbname',REPAIR_ALLOW_DATA_LOSS )吗？好，我再试试...
      

  11.   

    好象MSSQLSERVER6.5没有这个命令呀？
      

  12.   

    如果已经DBCC CHECKDB('yourdbname',REPAIR_ALLOW_DATA_LOSS )就不必DBCC CHECKALLOC ('yourdbname',REPAIR_ALLOW_DATA_LOSS )。
    一般推荐用DBCC CHECKALLOC ('yourdbname',REPAIR_ALLOW_DATA_LOSS )，因为你的错误是在分配存储上，CHECKALLOC速度快。
      

  13.   

    Haiwer(海阔天空)兄：
    Incorrect DBCC command. Please check the Commands Reference Manual for the correct DBCC syntax and options.
    DBCC execution completed. If DBCC printed error messages, see your System Administrator.
      

  14.   

    Haiwer(海阔天空)兄：另外，抽空帮忙看看
    http://www.csdn.net/expert/topic/503/503421.shtm
      

  15.   

    现在变得很奇怪了，你DBCC CHECKDB没有错，
    重建索引(DBCC DBREINDEX )时，报：
    Extent chain for object 180195692 is not correctly linked.你试一下：
    select * from sysobjects where id=180195692看是不是一个索引，是的话手工删除再建立。
      

  16.   

    删除这条记录吗？
    helhw1 180195692 1 U  0 115 1 1 2001-08-22 14:45:06.077 2001-08-22 14:45:06.077 0 0 0 0 0 513 0
      

  17.   

    dbcc checktable ('helhw1')试过没有？
      

  18.   

    试过了：
    Checking helhw1
    The total number of data pages in this table is 2151.
    Table has 59297 data rows.
    DBCC execution completed. If DBCC printed error messages, see your System Administrator.
      

  19.   

    你可以试一试如下语句：将中间的字段，表换成你自己的
    然后删除重复的记录。
    SELECT [图号], [项目], [装置], [专业]
    FROM 工程图
    WHERE [图号] In (SELECT [图号] FROM [工程图] As Tmp GROUP BY [图号] HAVING Count(*)>1 )
    ORDER BY [图号]
    还不行的话，你在表中添加一个字段，
    然后将字段信息放成记录号。
    再查，删除记录号重复的就可以了
      

  20.   

    to:QQ576006(Ken)=================>不要捣乱！！！！！！！！！！！
      

  21.   

    to：　supsuccess(口气不小)　
        你的表是不是没有问题了？
      

  22.   

    还是那样！怎么办？我用DROP TABLE 都不管用.
      

  23.   

    你的问题越来越奇怪了，你DBCC CHECKDB没有错，
    dbcc checktable ('helhw1')也没有错
    重建索引(DBCC DBREINDEX )时，报：
    Extent chain for object 180195692 is not correctly linked.
    drop table helhw1不行，最后问你一次了，drop table helhw1时报什么错，我快无能为力了！
      

  24.   

    服务器: 消息 1117，级别 21，状态 9，行 1
    Extent chain for object 180195692 is not correctly linked.连接中断
      

  25.   

    Haiwer(海阔天空)兄，这么麻烦你，我都不好意思了！要不你以后想起来再说吧，先休息休息！
      

  26.   

    to：　supsuccess(口气不小)　
       下午因为有事，没解决就走了，这个不是麻烦和累的问题，解决不了问题我也上火！
       看来如　bluepower2008(蓝色力量)　说的，硬盘有问题，但怎么解决呢？
       我觉得还是某个索引的问题，你试着一个一个删除这个表的索引，看在什么时候出错误。
      

  27.   

    好吧，先这样！谢谢Haiwer(海阔天空)！揭贴！以后少不了麻烦你！...
      

  28.   

    海兄的功底的确深厚，这个帖子也可以放到精华区了，问得精彩，答得漂亮！
    最后再补充一下，建议supsuccess(口气不小)在操作系统级对磁盘做一次完全扫描，来查出磁盘的坏块。
    不能删表的原因就是因为那个索引出了问题，删表的同时会删除该表建立的所有索引，如果有一个索引的某个页面存在坏的磁盘扇区上，就会出现删表不成功。