
|
If you were logged in you would be able to see more operations.
|
|
|
| Planning Status: |
Unspecified
|
|
Here's an extract from two isql sessions:
F:\fb2dev\fbbuild\firebird25\temp\Win32\Debug\firebird\bin>isql -user sysdba
-pass masterkey
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'testsec.fdb';
SQL> create user cvc password 'cpp';
SQL> create table t(a int);
SQL> grant update(a) on t to user cvc;
SQL> ^Z
F:\fb2dev\fbbuild\firebird25\temp\Win32\Debug\firebird\bin>isql TESTSEC.FDB
-user cvc -pass cpp
Database: TESTSEC.FDB, User: cvc
SQL> alter table t alter column a to "A2";
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-MODIFY RDB$RELATION_FIELDS failed
-no permission for control access to
-no permission for <Missing arg #1 - possibly status vector overflow> access
to <Missing arg #2 - possibly status vector overflow> <Missing arg #3 -
possibly status vector overflow>
SQL> ^Z
This is what happens in v3 and v2.5. Going backwards, v2.1 fails in a more elegant way:
SQL> alter table t alter column a to a2;
Statement failed, SQLCODE = -607
unsuccessful metadata update
-MODIFY RDB$RELATION_FIELDS failed
-no permission for control access to
-no permission for control access to @2? @3?
I didn't test v2.0 but I wouldn't be surprised if the message is screwed, too.
|
|
Description
|
Here's an extract from two isql sessions:
F:\fb2dev\fbbuild\firebird25\temp\Win32\Debug\firebird\bin>isql -user sysdba
-pass masterkey
Use CONNECT or CREATE DATABASE to specify a database
SQL> create database 'testsec.fdb';
SQL> create user cvc password 'cpp';
SQL> create table t(a int);
SQL> grant update(a) on t to user cvc;
SQL> ^Z
F:\fb2dev\fbbuild\firebird25\temp\Win32\Debug\firebird\bin>isql TESTSEC.FDB
-user cvc -pass cpp
Database: TESTSEC.FDB, User: cvc
SQL> alter table t alter column a to "A2";
Statement failed, SQLSTATE = 42000
unsuccessful metadata update
-MODIFY RDB$RELATION_FIELDS failed
-no permission for control access to
-no permission for <Missing arg #1 - possibly status vector overflow> access
to <Missing arg #2 - possibly status vector overflow> <Missing arg #3 -
possibly status vector overflow>
SQL> ^Z
This is what happens in v3 and v2.5. Going backwards, v2.1 fails in a more elegant way:
SQL> alter table t alter column a to a2;
Statement failed, SQLCODE = -607
unsuccessful metadata update
-MODIFY RDB$RELATION_FIELDS failed
-no permission for control access to
-no permission for control access to @2? @3?
I didn't test v2.0 but I wouldn't be surprised if the message is screwed, too.
|
Show » |
|
I also tend to disagree that the cryptic "for @1? access to @2? @3?" is more informative to end users than what v2.5/v3.0 is showing.