I just noticed that roles are case sensitive when they are created
quoted, is that correct behavior?
I have noticed several problems with this:
1) With Jaybird I am unable to use the role userrights2 (a role
userrights or USERRIGHTS works fine. Maybe Jaybird is adding the
rolename dpb item
On 25-10-2013 17:50, Vlad Khorsun wrote:
BTW: Would it be possible to include the name of the actual constraint
that was violated?
CREATE TABE T
(
F1 INT NOT NULL,
F2 INT CHECK(F2 = 0)
)
what constraint name would you like to report in both cases ? :)
Doesn't that get assigned an
26.10.2013 13:29, Mark Rotteveel wrote:
I just noticed that roles are case sensitive when they are created
quoted, is that correct behavior?
It is. Roles are regular SQL identifiers.
Dmitry
--
October Webinars:
On 26-10-2013 12:10, Dmitry Yemanov wrote:
26.10.2013 13:29, Mark Rotteveel wrote:
I just noticed that roles are case sensitive when they are created
quoted, is that correct behavior?
It is. Roles are regular SQL identifiers.
Ok, then how do I need to add a case sensitive role to the dpb to
26.10.2013 14:30, Mark Rotteveel wrote:
Ok, then how do I need to add a case sensitive role to the dpb to get it
to work?
Put it there with quotes.
Dmitry
--
October Webinars: Code for Performance
Free Intel
On 26-10-2013 12:52, Dmitry Yemanov wrote:
26.10.2013 14:30, Mark Rotteveel wrote:
Ok, then how do I need to add a case sensitive role to the dpb to get it
to work?
Put it there with quotes.
I tried that, it didn't work (with Jaybird).
Mark
--
Mark Rotteveel
On 26-10-2013 12:56, Mark Rotteveel wrote:
On 26-10-2013 12:52, Dmitry Yemanov wrote:
26.10.2013 14:30, Mark Rotteveel wrote:
Ok, then how do I need to add a case sensitive role to the dpb to get it
to work?
Put it there with quotes.
I tried that, it didn't work (with Jaybird).
If I
26.10.2013 16:07, Mark Rotteveel wrote:
If I explicitly specify the connection dialect (isc_dpb_sql_dialect),
then it does work. I was under the assumption that if no explicit
dialect is specified, that Firebird uses dialect 3. Is that assumption
wrong?
It is wrong. No dialect passed means
26.10.2013 14:41, Dmitry Yemanov wrote:
No dialect passed means that the client is too old so that
it has no idea about SQL dialects. The engine implies the legacy dialect
1 in this case.
Strange logic it is.
How to find out what dialect to use for connection before connection?
When
On 26-10-2013 14:41, Dmitry Yemanov wrote:
26.10.2013 16:07, Mark Rotteveel wrote:
If I explicitly specify the connection dialect (isc_dpb_sql_dialect),
then it does work. I was under the assumption that if no explicit
dialect is specified, that Firebird uses dialect 3. Is that assumption
26.10.2013 16:52, Dimitry Sibiryakov wrote:
How to find out what dialect to use for connection before connection?
The dialect is needed before connection only to process the role name
properly. And you DO know whether your role name is mixed-case before
connection. So the usage pattern is
26.10.2013 15:17, Dmitry Yemanov wrote:
And you DO know whether your role name is mixed-case before connection.
How can I? Everything I have is a role name entered by user. Before
connection I have
no idea even what version of server is on other end of wire.
IMHO, database dialect must
12 matches
Mail list logo
