1。数据库表中,包含一些系统表,数据库中所有物件的定义都记录在这些系统表中。2。创建新用户的时候,系统会自动赋与 Public 权限, Public 权限却省情形下,对系统表有读权限。syscolumns,syscomments,sysobjects3。如果想隐藏你的表结构,你可以取消你的用户对下列三个系统表的读权限,这样,用户没有常规的办法读到你的表结构,他甚至根本无法知道你的系统中都设计了哪些表,因为没有 sysobjects 表的读权限4。但是,用户仍然可以通过查询适当的 INFORMATION_SCHEMA.VIEWS 获得你所要隐藏的资料,所以,对用户隐藏表的结构,需要进行复杂的权限配置。 另外,对这类问题,用户权限是唯一需要考虑的问题,至于数据库是放在用户这边还是其它地方并不重要,即使放在用户物理接触不到的地方,用户仍然可以远程查询到相关资料。
1。数据库表中,包含一些系统表,数据库中所有物件的定义都记录在这些系统表中。2。创建新用户的时候,系统会自动赋与 Public 权限, Public 权限却省情形下,对系统表有读权限。3。如果想隐藏你的表结构,你可以取消你的用户对下列三个系统表的读权限,这样,用户没有常规的办法读到你的表结构,他甚至根本无法知道你的系统中都设计了哪些表,因为没有 sysobjects 表的读权限syscolumns,syscomments,sysobjects4。但是,用户仍然可以通过查询适当的 INFORMATION_SCHEMA.VIEWS 获得你所要隐藏的资料,所以,对用户隐藏表的结构,需要进行复杂的权限配置。 另外,对这类问题,用户权限是唯一需要考虑的问题,至于数据库是放在用户这边还是其它地方并不重要,即使放在用户物理接触不到的地方,用户仍然可以远程查询到相关资料。
to:zqllyh(找感觉) 这是我在csdn上根据你的提示找的,我回去试一试~~~~~~~~~~~~ (绝对原文,没有更改~~~~~~~~~~~~~~) 好消息!!!知道这个表是怎么回事了:D我把这个文件下载来研究了一番。确实是企业管理器里看不到表名,但这个表是存在的,用语句也可以操作。而且我用查询分析器出现以下现象: 1、用: select name,id from sysobjects where xtype='U' 看不到表名2、用: select id,name,len(name),datalength(name),cast(name as binary) from sysobjects where name='table1' 看得到表名3、用: select id,name,len(name),datalength(name),cast(name as binary) from sysobjects where id=357576312 也看不到表名所以觉得数据库文件里可能不一致,有的地方存有表名,有的地方表名被清空了。所以我在数据库里创建了一个新表table2,打开二进制文件进行查找,发现table2被找到三处,而table1只找到两处。所以有一处被清空了。最后确定了是在偏移地址 0x11646 处被清空了。将这里的连接几位改成"T a b l e 1" 。 改完应该从OX11642开始是: 01 00 3e 00 54 00 61 00 62 00 6c 00 65 00 31 00 再在SQLSERVER里刷新一下(其实中间做了脱机、联机的操作了的),就看到这个表名了。我觉得这可能与索引的存储有关系。sysobjects建有三个索引,其中sysobjects是按字段id建的是簇集索引。ncsysobjects按字段name+id,非簇集索引。 我觉得这个被改的地方是簇集索引所在的地方。 所以上面第一个SQL语句在查询时会用簇集索引sysobjects来得到name值,所以是空的。 第二个SQL语句因为WHERE后用NAME做条件,所以会用到索引ncsysobjects,这个索引的键值是正常的,所以能得到name值。 第三个SQL语句WHERE后是用ID做条件,所在也是用sysobjects这个索引来取值,所以也是空的。在查询分析器里显示所有表估计也是用第一个SQL语句那样的,所以是看不到表名了。
to:zqllyh(找感觉) 我根据你的提示我在csdn上搜索了一下,找了以下部分 好消息!!!知道这个表是怎么回事了:D我把这个文件下载来研究了一番。确实是企业管理器里看不到表名,但这个表是存在的,用语句也可以操作。而且我用查询分析器出现以下现象: 1、用: select name,id from sysobjects where xtype='U' 看不到表名2、用: select id,name,len(name),datalength(name),cast(name as binary) from sysobjects where name='table1' 看得到表名3、用: select id,name,len(name),datalength(name),cast(name as binary) from sysobjects where id=357576312 也看不到表名所以觉得数据库文件里可能不一致,有的地方存有表名,有的地方表名被清空了。所以我在数据库里创建了一个新表table2,打开二进制文件进行查找,发现table2被找到三处,而table1只找到两处。所以有一处被清空了。最后确定了是在偏移地址 0x11646 处被清空了。将这里的连接几位改成"T a b l e 1" 。 改完应该从OX11642开始是: 01 00 3e 00 54 00 61 00 62 00 6c 00 65 00 31 00 再在SQLSERVER里刷新一下(其实中间做了脱机、联机的操作了的),就看到这个表名了。我觉得这可能与索引的存储有关系。sysobjects建有三个索引,其中sysobjects是按字段id建的是簇集索引。ncsysobjects按字段name+id,非簇集索引。 我觉得这个被改的地方是簇集索引所在的地方。 所以上面第一个SQL语句在查询时会用簇集索引sysobjects来得到name值,所以是空的。 第二个SQL语句因为WHERE后用NAME做条件,所以会用到索引ncsysobjects,这个索引的键值是正常的,所以能得到name值。 第三个SQL语句WHERE后是用ID做条件,所在也是用sysobjects这个索引来取值,所以也是空的。在查询分析器里显示所有表估计也是用第一个SQL语句那样的,所以是看不到表名了。但是有一个问题是,怎样编辑二进制文件呢?不要笑哈
Permission()
知道表的结构没问题的
另外,对这类问题,用户权限是唯一需要考虑的问题,至于数据库是放在用户这边还是其它地方并不重要,即使放在用户物理接触不到的地方,用户仍然可以远程查询到相关资料。
另外,对这类问题,用户权限是唯一需要考虑的问题,至于数据库是放在用户这边还是其它地方并不重要,即使放在用户物理接触不到的地方,用户仍然可以远程查询到相关资料。
查一下有关虚拟表讨论的这几个贴吧。
(绝对原文,没有更改~~~~~~~~~~~~~~)
好消息!!!知道这个表是怎么回事了:D我把这个文件下载来研究了一番。确实是企业管理器里看不到表名,但这个表是存在的,用语句也可以操作。而且我用查询分析器出现以下现象:
1、用:
select name,id from sysobjects where xtype='U'
看不到表名2、用:
select id,name,len(name),datalength(name),cast(name as binary)
from sysobjects
where name='table1'
看得到表名3、用:
select id,name,len(name),datalength(name),cast(name as binary)
from sysobjects
where id=357576312
也看不到表名所以觉得数据库文件里可能不一致,有的地方存有表名,有的地方表名被清空了。所以我在数据库里创建了一个新表table2,打开二进制文件进行查找,发现table2被找到三处,而table1只找到两处。所以有一处被清空了。最后确定了是在偏移地址 0x11646 处被清空了。将这里的连接几位改成"T a b l e 1" 。
改完应该从OX11642开始是:
01 00 3e 00 54 00 61 00 62 00 6c 00 65 00 31 00
再在SQLSERVER里刷新一下(其实中间做了脱机、联机的操作了的),就看到这个表名了。我觉得这可能与索引的存储有关系。sysobjects建有三个索引,其中sysobjects是按字段id建的是簇集索引。ncsysobjects按字段name+id,非簇集索引。
我觉得这个被改的地方是簇集索引所在的地方。
所以上面第一个SQL语句在查询时会用簇集索引sysobjects来得到name值,所以是空的。
第二个SQL语句因为WHERE后用NAME做条件,所以会用到索引ncsysobjects,这个索引的键值是正常的,所以能得到name值。
第三个SQL语句WHERE后是用ID做条件,所在也是用sysobjects这个索引来取值,所以也是空的。在查询分析器里显示所有表估计也是用第一个SQL语句那样的,所以是看不到表名了。
我根据你的提示我在csdn上搜索了一下,找了以下部分
好消息!!!知道这个表是怎么回事了:D我把这个文件下载来研究了一番。确实是企业管理器里看不到表名,但这个表是存在的,用语句也可以操作。而且我用查询分析器出现以下现象:
1、用:
select name,id from sysobjects where xtype='U'
看不到表名2、用:
select id,name,len(name),datalength(name),cast(name as binary)
from sysobjects
where name='table1'
看得到表名3、用:
select id,name,len(name),datalength(name),cast(name as binary)
from sysobjects
where id=357576312
也看不到表名所以觉得数据库文件里可能不一致,有的地方存有表名,有的地方表名被清空了。所以我在数据库里创建了一个新表table2,打开二进制文件进行查找,发现table2被找到三处,而table1只找到两处。所以有一处被清空了。最后确定了是在偏移地址 0x11646 处被清空了。将这里的连接几位改成"T a b l e 1" 。
改完应该从OX11642开始是:
01 00 3e 00 54 00 61 00 62 00 6c 00 65 00 31 00
再在SQLSERVER里刷新一下(其实中间做了脱机、联机的操作了的),就看到这个表名了。我觉得这可能与索引的存储有关系。sysobjects建有三个索引,其中sysobjects是按字段id建的是簇集索引。ncsysobjects按字段name+id,非簇集索引。
我觉得这个被改的地方是簇集索引所在的地方。
所以上面第一个SQL语句在查询时会用簇集索引sysobjects来得到name值,所以是空的。
第二个SQL语句因为WHERE后用NAME做条件,所以会用到索引ncsysobjects,这个索引的键值是正常的,所以能得到name值。
第三个SQL语句WHERE后是用ID做条件,所在也是用sysobjects这个索引来取值,所以也是空的。在查询分析器里显示所有表估计也是用第一个SQL语句那样的,所以是看不到表名了。但是有一个问题是,怎样编辑二进制文件呢?不要笑哈