:: First, a request that you avoid cross-posting to multiple
:: lists. And, when you think you must do so, delete the [list

Sorry about that - I only did that on the first 2 messages when I was unsure
where the problem was located - FB or the .NET provider.

:: tag] from the Subject before you do so. A lot of us are
:: monitoring multiple lists involving scores of threads daily.

Im not sure how it got both subjects, it should have come back to my machine
as separate messages.

:: It's not acceptable list etiquette for people to screw up
:: our list filters. - ^hb

Im amazed that you are filtering on subject and not recipient though. :)

:: Take Alan McDonald's advice on board....it's always the
:: right thing to do to inform yourself in advance of the
:: collateral effects of changing metadata and to make existing
:: data consistent with the change you intend to make before
:: you make the change.

But as I understand it, my change was valid. And in fact I've made this same
change on other fields before with no problems.

:: However, I've reproduced the behaviour you describe and I
:: think it is sufficiently inconsistent to be regarded as a
:: bug. We "old hands" are not used to being able to put
:: unique indexes or constraints on nullable columns and would
:: not have found this in the normal run of things.

Actually Im a bit confused by this. Wasn't it Bill Karwin that was always
saying "null is a state, not a value"? In Oracle, SQL server etc it treats
it this way too. DBISAM was the only DB that treated null as a value and
caused significant problems regardig this (I think they've finally addressed
this regarding unique indexes in the latest versions). So if null is not a
value - why should FB be seeing it as a violation of a unique in any case?

:: I have a testcase which I'll give to Claudio, as I think it
:: was he who was responsible for the change in DSQL that
:: causes an explicit or implicit null to be presented to the
:: parser as a literal blank under some conditions. If it

Aah - now this makes more sense.

:: happened under all conditions, it could be regarded as a
:: rule, but it isn't consistent. At least it is reproducibly
:: inconsistent :-) and you've found a workaround for it for now.

That being don't use the index? :)

:: However, I'll need to download v.1.5.2 RC 5 first and just
:: do a reality check that the inconsistency is still
:: there...so be patient...I'm on a slow dialup link here in
:: the Wopwops, where "broadband" is still the red satiny thing
:: that male Flamenco dancers wear around their waists.

Thanks. As per your other message we'll consider upgrading when we can.