While I can understand your frustration, I think it is important to think about the tone in our postings here. Hydrocephalus is one of the most common birth defects, and it's not terribly unlikely that someone who reads this has a family member or someone else in his proximity who suffers from this condition.
[EMAIL PROTECTED] wrote: > "Fixed"? Up until now, I didn't think it was possible for > crackpot theories to be implemented in computer science. > This is absolutely the craziest thing I've ever heard. Still, many people with lots of experience in databases use it, and prefer it for certain kinds of applications. All systems have limitations and deviations, and those limitations and deviations are stated more clearly for SQLite than for most commercial products at least. The market leader Oracle still can't store empty strings in VARCHAR fields for instance. They are silently converted to NULL. I'm pretty sure that has been in clear violation to the official spec since 1986 at least. As far as I understand, noone here is forcing you to use SQLite, and with your long experience of MS Access I'd expect you to be fairly used to "almost SQL"... It's some time since I used Jet/Access now, but I had much more problems with that than I've had with SQLite. SQLite is built in Tcl, by someone who appreciates the way Tcl works, with its weak typing. I don't think Tcl's type handling is nearly as clever as Python's, but I think it's a good thing that Python's standard lib finally has a DB-API compliant module, and while I would have preferred something that was closer to standard SQL, I don't know of a better candidate than SQLite. It's good that it's usable without a server setup, and that it's very light weight. A Jet engine is obviously not an option, and I would have preferred SQLite even if Jet was open source and worked on all platforms. (Well, if JET *was* open source, I suspect it would have been fixed by now.) It's possible that one could have used the embedded version of Firebird instead, but in my experience that's not nearly as lean or easy to deploy. With your long experience of Access and SQL Server I'm sure you know well that any attempt to build a working database application requires extensive knowledge of the backend to understand its peculiarities and limitations. The list of software projects where not quite competent developers built Access applications that worked ok in small scale tests and failed catastrophically in real life is looong... Of course, if you've stayed with one vendor for 15 years, I can imagine that you've forgotten how long it took you Having worked with half a dozen backends or so, I'm no longer surprised that SQL can be interpreted in so many ways... I agree that SQLite is unique in it's approach to typing, but if you are aware of this, it's really not a big problem. -- http://mail.python.org/mailman/listinfo/python-list
