Проблемы с разрешением таблицы при попытке удалить таблицу - PullRequest
1 голос
/ 18 июля 2010

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 при удалении, создании, чтении или записи в таблицу. Тем не менее, я предоставил все на имя таблицы для общественности и предоставил DBA для общественности. Я также выполнил те же заявления о предоставлении гранта в 4.10.

Нужно ли указывать владельца таблицы при отбрасывании таблицы, например:

DROP TABLE "pcuser".tablename;

Извините, у меня нет документации по ISQL 4.10.

Ниже приведены экранные выходы execute.out строк SYSTABAUTH и SYSTABLES для имени таблицы:

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            [                                ]
                   [                                ]

Ниже приведены два процесса в моем приложении. Первый корректно работает, но второй завершается ошибкой с ошибкой 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....

1 Ответ

3 голосов
/ 18 июля 2010

Запуск "finderr -545", я получаю информацию:

-545 Нет разрешения на запись для таблицы имя таблицы.

Проверьте прилагаемый код ошибки ISAM для получения дополнительной информации. С этим сервер базы данных, база данных представляет собой каталог с именем dbname.dbs, в то время как таблицы и индексы являются файлами в этом каталоге. Вам нужно иметь доступ ко всем этим файлам для чтения и записи, чтобы обычные функции базы данных.

Вам нужно будет просмотреть права доступа к каталогу в каталоге базы данных (dbname.dbs). Если вы вошли в систему как «pcuser», вам необходимо иметь каталог и иметь разрешение на удаление файлов из него (и создание файлов и т. Д.).

Я не уверен, как ISQL и SE из DOS (где действительно не было пользователей) адаптируются к современным версиям Windows (где есть пользователи).

Если бы вы работали на какой-либо другой платформе, я бы посоветовал вам отказаться от «GRANT DBA TO PUBLIC»; это рецепт катастрофы. Я до сих пор не убежден, что это хорошая идея, но у меня нет каких-либо подробностей, на которые я мог бы указать, чтобы окончательно возразить против этого - но это кажется неправильным; Вам следует позаботиться о том, кто обращается к базе данных и у кого есть возможность восстановить базу данных.

Отвечая на вопрос «Нужно ли указывать имя пользователя в операторе DROP TABLE?», Ответ «Нет». Сообщение об ошибке от стадии после того, как запрос был проанализирован и проверен; он понимает имя таблицы. Просто у пользователя, выполняющего запрос, недостаточно прав для выполнения запрошенной операции.

...