Question

Informix-SQL（SE）4.10.DD6（MS-DOS 6.22）：

我创建了一个表：“pcuser”.tablename。我试图删除此表：

DROP TABLE tablename;

并收到以下错误消息：

545: No write permission for table pcuser.tablename.

由于我的应用程序是单用户而且我不关心限制任何表的权限，因此我安装了ISQL 4.10而没有密码保护（即启动SE引擎不需要用户名或密码）。因此默认且唯一的用户名/表所有者始终是“pcuser”。使用ISQL 2.10，在删除，创建，读取或写入表时，我不必指定“table-owner”.tablename。但是我确实将所有的tablename授予公众，并向公众授予dba。我还在4.10中执行了相同的授权声明。

删除表格时是否必须指定表所有者：

DROP TABLE "pcuser".tablename;

抱歉，我没有ISQL 4.10的文档。

以下是对于tablename的SYSTABAUTH和SYSTABLES行的perform.out屏幕输出：

SYSTABAUTH:

grantor            [pcuser  ]
grantee            [public  ]
tabid              [102        ]
tabauth            [su-idxa]


SYSTABLES:

tabname            [tablename           ]
owner              [pcuser  ]
dirpath            [C:\DBFILES.DBS\TABLENAME        ]
                   [                                ]
tabid              [102        ]
rowsize            [256   ]
ncols              [48   ]
nindexes           [5     ]
nrows              [1082594    ]
created            [07-13-2010]
version            [9          ]
tabtype            [T]
audpath            [                                ]
                   [                                ]

以下是我的应用中的两个sql proc。第一个正确执行，但第二个在drop table语句中使用错误545失败：

{CREATEDB.SQL - First SQL Proc}

DROP DATABASE dbfiles;

CREATE DATABASE dbfiles;

CREATE TABLE tablename
    (
     col1 char(18),
     col2 char(60),
     [...]
    ) in "C:\DBFILES.DBS\TABLENAME";

LOAD FROM "tablename.unl" INSERT INTO tablename;

CREATE UNIQUE INDEX tablename_idx1 ON tablename (col1);

GRANT ALL ON tablename TO PUBLIC;

GRANT DBA TO PUBLIC;

UPDATE STATISTICS;

---

{DROPTAB.SQL - Second SQL Proc}

DROP TABLE tablename;
           ^
           ERROR 545: No Write Permission....

Answer 1

运行“finderr -545”，我会收到信息：

-545没有表table-name的写权限。

查看随附的ISAM错误代码以获取更多信息。有了这个   数据库服务器，数据库是名为dbname.dbs的目录，   而表和索引是该目录中的文件。你需要   拥有对所有这些文件的读写权限以便锻炼   正常的数据库功能。

您需要查看数据库目录（dbname.dbs）上的目录权限。如果您以'pcuser'身份登录，则需要拥有该目录并有权从中删除文件（以及创建文件等）。

我不确定DOS中的ISQL和SE（真正没有用户的地方）如何适应现代版本的Windows（有用户）。

如果你在任何其他平台上运行，我会建议你反对'GRANT DBA TO PUBLIC';这是灾难的秘诀。我仍然不相信这是一个好主意，但我没有任何具体的内容可以指出它最终反对它 - 但它感觉不对;你应该关心谁访问数据库以及谁有能力重建数据库。

回答有关'我是否必须在DROP TABLE语句中指定用户名？'的问题，答案为“否”。错误消息来自解析和验证查询后的阶段;它理解表名。只是运行查询的用户似乎没有足够的权限来执行请求的操作。

尝试删除表时表权限问题

1 个答案: