>Stored procedures aren't really needed for Sqlite, since the program you write around Sqlite can certainly implement any 'stored' procedures itself. This argument applies equally well to all database engines. There are several advantages to using stored procedures. (I won't list them, Google them). From those, only the client-server over network speedup is irrelevant to SQLite3. I believe the number of people (including programmers) who use SQLite3 as a stand-alone database tool is vastly underestimated. SQLite3 has become very powerful over the years due to its relative simplicity, single-file database, and immediacy. Many who would otherwise use a client/server database now find it more than enough to use SQLite3 as it does almost everything the bigger ones do with far less overhead and practically zero setup effort. Stored procedures would make their life quite a bit easier in many circumstances. A **minimal** implementation of stored procedures would be a welcome addition to what is already almost a full-fledged database engine. By 'minimal' I mean at least: 1. Be able to group several statements together 2. Allow parameters when calling the proc. 3. A simple method to `rollback` and exit after each statement if there are errors or (by default) continue to the next statement. That's all. No variables, or other perhaps complicated programming structures found in larger database engines.  is already implemented in triggers.  is already setup in the CLI with the `.parameter` command. It needs to become part of the core using the `PROC(PARM1,PARM2,...)` syntax.