I don't understand how this new keyword, USESCHEMA=0,1,2, is supposed to work.
If the user logs on with SYSDBA, isn't the default or implied vitual schema supposed to be RDB$OWNER?
So you don't have to qualify tables with RDB$OWNER if the connection userid is SYSDBA. In other words,
SYSDBA logon ID implies RDB$OWNER. Another case when you might imply RDB$OWNER is when the user logs on with a different ID than SYSDBA, but does have DBA authority and wants to logon as DBA role (an oracle thang) then you would imply the RDB$OWNER again. Now, you would not imply RDB$OWNER even if the user has DBA privileges if the user chooses not to logon as DBA role. In that case, RDB$OWNER system tables would have to be explictily referenced like RDB$OWNER.<FB System Table>.
So, my suggestion is to add a boolean connection parameter: logon as DBA. IF TRUE, then the user can reference system tables without having to qualify them as RDB$OWNER.<system table name>. All non-system tables would never need to be qualified since anything but the system tables kind of belongs to everybody else, or every other kind of login user until such time when FB supports schemas, then and only then could you differentiate between user tables.
From: Vladimir Tsvigun <praktik@...>
Sent: Thu, 23 Mar 2006 12:50:17 +0200
Subject: Re: [Firebird-odbc-devel] SQPProcedures not working corretly
I am sorry!
You have appeared sole to whom it it is necessary :-)
Please, check up new build v2.0.0129
use new keyword for connect string
USESCHEMA=1 or USESCHEMA=2
use select for create new DSN
"Remove SCHEMA from SQL query"
"Use full SCHEMA"
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
Firebird-odbc-devel mailing list