I agree with Greg, the most irksome feature of SQLite is the case sensititvity - it's one of the few things MS got right with SQLserver. I know this is more mainstream/standard SQL behaviour but it's outdated in modern SQL applications that nearly always do some kind of linguistic searching. In fact, I'd go one step further and advocate making SQLite case-insensitive as a rule. I'm waiting for the flames....... Steve
As far as I'm concerned, the issue of case-sensitive vs insensitive is related to locale or nationality specific matters. It involves treating a pair of different characters as being the same character. Besides our latin characters, does any other written language have such a concept as upper/lowercase? Whichever is available will probably have its fans. Case-insensitive may be more like a "natural human language" whereas the other may be less, or not.
I think that both methods should be supported, perhaps with a compile time directive determining the default, and a run-time directive changing it on a case by case basis.
One thing to make absolutely certain, though, is that the SQLite API provides a means to programmatically determine at runtime what behaviour is being used. If nothing else, it allows an application which either expects one behaviour or is able to adapt to either, to know how to talk to the database such that its expectations match reality.
Personally, I would hate for an application which expects a case-sensitive unique field, and inserts multiple rows that it thinks are distinct, only to have one fail or overwrite the other because some case-insensitive rule says they are actually the same.
-- Darren Duncan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
