On Tue, 2005-08-23 at 00:04 +0200, Edwin Knoppert wrote: > All i meant is that sqlite is created by a c programmer, like my colleague > he seems to forget there are different languages but he doesn't care. >
Actually, I'm a TCL programmer. I only resort to C code to write new TCL extensions. I personally never use the SQLite C API except when I am working on internals of the TCL bindings. I use SQLite in my professional work a lot, but I always access it through the TCL bindings. Even when I am working on SQLite itself, I almost always access it through the TCL bindings. (All of the test scripts are writtne in TCL.) And this brings up an important point: I'm increasingly aware of the fact that the C API to SQLite really wants to be wrapped. There are a lot of loose ends that can cause complication and trouble if you try to use the C API directly in your application. Things like the infamous SQLITE_SCHEMA returns. And the notorious SQLITE_BUSY. And then the recent conversation about how to tell if the file is really a database or not. These kinds of things are best dealt with once in a wrapper and then forgotten. You do not want to have to be worrying about error return codes when you are trying to make the next great klller app. Programmers need to save their brain cycles to focus on the really hard problems, not on handling lots of pesky return codes. Most people who are using SQLite successfully have, I imagine, either written their own wrappers around the core API (which is not hard as I do provide you with a lot of helper routines such as sqlite3_vmprintf and friends) or they are using an existing wrapper written by someone else. If you are not doing this - if you are trying to make low-level SQLite API calls like sqlite3_prepare and sqlite3_step for each bit of SQL you want to run, then let me suggest that you are using the library incorrectly. That is way too much work. I expose those calls because they provide you with a lot of control and give wrapper writers the freedom to do lots of interesting things with the database. If you are working on an application that just needs access to data, sqlite3_prepare and sqlite3_step are way too low level. Find a wrapper suitable for your needs and use it instead. Or write your own wrapper if an appropriate one can't be found. This will result in a program that is easier to write, easier to maintain, has fewer bugs, and just works better. -- D. Richard Hipp <[EMAIL PROTECTED]>
