On 12 Sep 2006 00:15:41 -0700, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Just to be fair... > > You do hear many people claiming exactly that, and the primary > complaint is often exactly the same one that's being levelled against > sqlite here (it's incredibly lax with types and does sometimes > mystifying conversions rather than pointing out programmer errors--and > yes that's intentionally loaded language that I don't necessarily agree > with, it's a common argument though.). True enough. Yet not a single conversion is undocumented in SQLite, nor is its type affinity. It works exactly as advertised. And MySQL's chief type conversion gotchas -- primarily dates/times I think -- were also clearly addressed in the documentation, and where changed in later versions of MySQL. Then there is, as I think another person pointed out on this thread, Oracle's silent conversion of empty strings to NULLs in VARCHAR fields -- talk about mystifying. What about Oracle's native date format, which also has no relation to the standard? I have little experience with Oracle, but from what I can tell, to get it to display dates in standard (ISO) format, you have to set the NLS_DATE_FORMAT at the session or database level, which requires either additional SQL commands, or administrative intervention. More so-called non-SQL compliant behavior, although hardly a surprise (or even a problem) to someone who is experienced with Oracle. The bottom line: to use *any* database effectively, big or small, one has to read its documentation, not the SQL standard. -- http://mail.python.org/mailman/listinfo/python-list
