const
SQLITE_OK = 0; 返回成功
SQLITE_ERROR = 1; SQL错误或错误的数据库
SQLITE_INTERNAL = 2; An internal logic error in SQLite
SQLITE_PERM = 3; 拒绝访问
SQLITE_ABORT = 4; 回调函数请求中断
SQLITE_BUSY = 5; 数据库文件被锁
SQLITE_LOCKED = 6; 数据库中的一个表被锁
SQLITE_NOMEM = 7; 内存分配失败
SQLITE_READONLY = 8; 试图对一个只读数据库进行写操作
SQLITE_INTERRUPT = 9; 由sqlite_interrupt()结束操作
SQLITE_IOERR = 10; 磁盘I/O发生错误
SQLITE_CORRUPT = 11; 数据库磁盘镜像畸形
SQLITE_NOTFOUND = 12; (Internal Only)表或记录不存在
SQLITE_FULL = 13; 数据库满插入失败
SQLITE_CANTOPEN = 14; 不能打开数据库文件
SQLITE_PROTOCOL = 15; 数据库锁定协议错误
SQLITE_EMPTY = 16; (Internal Only)数据库表为空
SQLITE_SCHEMA = 17; 数据库模式改变
SQLITE_TOOBIG = 18; 对一个表数据行过多
SQLITE_CONSTRAINT = 19; 由于约束冲突而中止
SQLITE_MISMATCH = 20; 数据类型不匹配
SQLITE_MISUSE = 21; 数据库错误使用
SQLITE_NOLFS = 22; 使用主机操作系统不支持的特性
SQLITE_AUTH = 23; 非法授权
SQLITE_FORMAT = 24; 辅助数据库格式错误
SQLITE_RANGE = 25; 2nd parameter to sqlite_bind out of range
SQLITE_NOTADB = 26; 打开的不是一个数据库文件
SQLITE_ROW = 100; sqlite_step() has another row ready
SQLITE_DONE = 101; sqlite_step() has finished executing
数据库运行函数sqlite3_exec()与单步运行函数sqliet3_step()的返回值
SQLITE_OK/0 成功执行
SQLITE_ERROR/1 SQL错误或数据库不存在
SQLITE_INTERNAL/2 SQLite内部逻辑错误（没有使用）
SQLITE_PERM/3 访问许可禁止
SQLITE_ABORT/4 回调函数请求中止
SQLITE_BUSY/5 数据库文件被锁定
SQLITE_LOCKED/6 数据库中的一表被锁定
SQLITE_NOMEM/7 malloc()分配堆失败
SQLITE_READONLY/8 企图写只读数据库
SQLITE_INTERRUPT/9 操作被sqlie3_interrupt()中止
SQLITE_IOERR/10 磁盘I/O错误
SQLITE_CORRUPT/11 数据库文件变形
SQLITE_NOTFOUND/12 表或纪录没有找到（没有使用）
SQLITE_FULL/13 插入失败因为数据库满
SQLITE_CANTOPEN/14 不能打开数据库文件
SQLITE_PROTOCOL/15 数据库锁协议错误
SQLITE_EMPTY/16 数据库是空的
SQLITE_SCHEMA/17 数据库模式改变
SQLITE_TOOBIG/18 单行数据过多（没有使用）
SQLITE_CONSTRAINT/19 因约束违背而中止
SQLITE_MISMATCH/20 数据类型不匹配
SQLITE_MISUSE/21 库使用方法不当
SQLITE_NOLFS/22 主机不支持库中操作系统功能
SQLITE_AUTH/23 认证禁止
SQLITE_FORMAT/24 附属数据库格式错误
SQLITE_RANGE/25 sqlite3_bind()第2个参数超出范围
SQLITE_NOTADB/26 打开非数据库文件
SQLITE_ROW/100 sqlite3_step()有另一行数据就绪
SQLITE_DONE/101 sqlite3_step()完成执行，已无数据
多个进程可同时打开同一个数据库。多个进程可以同时进行SELECT 操作，但在任一时刻，只能有一个进程对数据库进行更改。
SQLite使用读、写锁控制对数据库的访问。（在Win95/98/ME等不支持读、 写锁的系统下，使用一个概率性的模拟来代替。）但使用时要注意： 如果数据库文件存放于一个NFS文件系统上，这种锁机制可能不能正常工作。 这是因为 fcntl() 文件锁在很多NFS上没有正确的实现。 在可能有多个进程同时访问数据库的时候，应该避免将数据库文件放到NFS上。 在Windows上，Microsoft的文档中说：如果使用 FAT 文件系统而没有运行 share.exe 守护进程，那么锁可能是不能正常使用的。那些在Windows上有很多经验的人告诉我： 对于网络文件，文件锁的实现有好多Bug，是靠不住的。如果他们说的是对的， 那么在两台或多台Windows机器间共享数据库可能会引起不期望的问题。
我们意识到，没有其它嵌入式的 SQL 数据库引擎能象 SQLite 这样处理如此多的并发。SQLite允许多个进程同时打开一个数据库， 同时读一个数据库。当有任何进程想要写时，它必须在更新过程中锁住数据库文件。 但那通常只是几毫秒的时间。其它进程只需等待写进程干完活结束。 典型地，其它嵌入式的SQL数据库引擎同时只允许一个进程连接到数据库。
但是，Client/Server数据库引擎（如 PostgreSQL, MySQL, 或 Oracle） 通常支持更高级别的并发，并且允许多个进程同时写同一个数据库。 这种机制在Client/Server结构的数据库上是可能的， 因为总是有一个单一的服务器进程很好地控制、协调对数据库的访问。 如果你的应用程序需要很多的并发，那么你应该考虑使用一个Client/Server 结构的数据库。但经验表明，很多应用程序需要的并发，往往比其设计者所想象的少得多。
当SQLite试图访问一个被其它进程锁住的文件时，缺省的行为是返回 SQLITE_BUSY。 可以在C代码中使用 sqlite3_busy_handler() 或 sqlite3_busy_timeout() API 函数调整这一行为。