On Fri, 30 May 2003, Brian Candler wrote:

<snip>
> Yeah, but how would you implement it as a layer on top of an SQL database?
> This is just one of the problems I came across:
>
> - In Oracle, "like" is case-sensitive (only)
> - In Sqlite, "like" is case-insensitive (only)
> - In Mysql, you have the choice of "like" or "ilike" operators
>
> It's pretty much impossible to layer consistent semantics on top of all
> three databases. I have had to approximate. In the case of Oracle, I have to
> issue queries of the form
>
>      "foo like ? or foo like ? or foo like ? or foo like ?",
>          var, var.downcase, var.upcase, var.capitalize
>
> It's awful. Even worse is date and time handling.

i fell your pain - and my application is nothing but data and time handling
which is why i'm so anti dbi.  in my mind dbi (or similar) give you as many
headaches with none of the perks (since you can't take advantage of db
specific feature w/o losing portability) - sort of like writing OO code in c++
;-) genericity is, all too often, evil.

-a
--
  ====================================
  | Ara Howard
  | NOAA Forecast Systems Laboratory
  | Information and Technology Services
  | Data Systems Group
  | R/FST 325 Broadway
  | Boulder, CO 80305-3328
  | Email: ara.t.howard / fsl.noaa.gov
  | Phone:  303-497-7238
  | Fax:    303-497-7259
  | ~ > ruby -e 'p % ^) .intern'
  ====================================