Ah, you have to add it as a 'unique' table constraint, if you add a
unique index it doesn't work. Odd, shouldn't you be able to do it
either way?
SQL spec defines behavior of unique constrain over null able field to
allow multiple
null for the fields participating in the constraint.
For In
of catch-22 as far as
adding a new unique column to an existing table).
- Original Message
From: Knut Anders Hatlen <[EMAIL PROTECTED]>
To: Derby Discussion
Sent: Tuesday, June 24, 2008 9:34:22 AM
Subject: Re: any feedback on this?
Alan Burlison writes:
>>> Derby 10.4
Alan Burlison <[EMAIL PROTECTED]> writes:
>>> Derby 10.4 allows multiple nulls for unique columns.
>>
>> I'm using 10.4.1.3 but it doesn't seem to work - is there some sort
>> of spacial chant I need to do to enable this?
>
> Ah, you have to add it as a 'unique' table constraint, if you add a
> un
Rick Hillegas wrote:
Some people have found it useful to add a CHECK constraint to the table
to verify that wrong values aren't leaking into the upper-case column
from somewhere in their application. Something like the following can
give you more peace of mind:
create table t
(
lastName va
Bryan Pendleton wrote:
How do people work around this at present? I absolutely *must* have
case-insensitive indexed searches in my application.
I store my critical string fields twice, in two separate columns, one
column has the user-desired case, and the other column has the same data
in all
Derby 10.4 allows multiple nulls for unique columns.
I'm using 10.4.1.3 but it doesn't seem to work - is there some sort of
spacial chant I need to do to enable this?
Ah, you have to add it as a 'unique' table constraint, if you add a
unique index it doesn't work. Odd, shouldn't you be able
Øystein Grøvlen wrote:
Derby 10.4 allows multiple nulls for unique columns.
I'm using 10.4.1.3 but it doesn't seem to work - is there some sort of
spacial chant I need to do to enable this?
--
Alan Burlison
--
Alan Burlison wrote:
I've hit another snag though - I want the index to be unique and I was
going to keep the case-converted column up-to-date using 'after'
triggers. However you can't use after triggers to populate a column
which has a unique index. If you use a multi-row insert, the trigge
Knut Anders Hatlen wrote:
Both of the above queries would normally use the index on upper_col, if
such an index is present.
Thanks.
I've hit another snag though - I want the index to be unique and I was
going to keep the case-converted column up-to-date using 'after'
triggers. However you
Alan Burlison <[EMAIL PROTECTED]> writes:
> Bryan Pendleton wrote:
>
>> I store my critical string fields twice, in two separate columns, one
>> column has the user-desired case, and the other column has the same data
>> in all upper case.
>>
>> Then, when I want to search without considering case
Suavi Ali Demir wrote:
for case insensitive index, you can have another column that holds lower-case
version of your original column. you can create an index on that lowercase
column and use it in your sql. you can use triggers to maintain the lowercase
column.
Something like this seems to
AIL PROTECTED]> wrote:
> From: Alan Burlison <[EMAIL PROTECTED]>
> Subject: Re: any feedback on this?
> To: "Derby Discussion"
> Date: Monday, June 23, 2008, 4:42 PM
> Rick Hillegas wrote:
>
> > I have commented on the issue. Your latest proposal
> sounds to
Bryan Pendleton wrote:
I store my critical string fields twice, in two separate columns, one
column has the user-desired case, and the other column has the same data
in all upper case.
Then, when I want to search without considering case, I take my search
terms, convert them to all upper case,
How do people work around this at present? I absolutely *must* have
case-insensitive indexed searches in my application.
I store my critical string fields twice, in two separate columns, one
column has the user-desired case, and the other column has the same data
in all upper case.
Then, when
Rick Hillegas wrote:
I have commented on the issue. Your latest proposal sounds to me like
DERBY-455 (expression indexes). That would be a very elegant, powerful
feature but I think that DERBY-481 (generated columns) entails less
effort and gives us most of the power of expression indexes. As
Geoff hendrey wrote:
I posted a comment with a suggestion on an approach for dealing with
case-insensitive comparisons.
Any feedback?
https://issues.apache.org/jira/browse/DERBY-1748?focusedCommentId=12606166#action_12606166
Hi Geoff,
I have commented on the issue. Your latest proposal sound
Geoff hendrey wrote:
I posted a comment with a suggestion on an approach for dealing with
case-insensitive comparisons.
Any feedback?
https://issues.apache.org/jira/browse/DERBY-1748?focusedCommentId=12606166#action_12606166
I find declaring the collation when defining the column is much more
I posted a comment with a suggestion on an approach for dealing with
case-insensitive comparisons.
Any feedback?
https://issues.apache.org/jira/browse/DERBY-1748?focusedCommentId=12606166#action_12606166
18 matches
Mail list logo
