The "CREATE TABLE" command is used to create a new table in an SQLite
database. A CREATE TABLE command specifies the following attributes of the
new table:
The name of the new table.
The database in which the new table is created. Tables may be
created in the main database, the temp database, or in any attached
The name of each column in the table.
The declared type of each column in the table.
A default value or expression for each column in the table.
A default collation sequence to use with each column.
Optionally, a PRIMARY KEY for the table. Both single column and
composite (multiple column) primary keys are supported.
A set of SQL constraints for each table. SQLite supports UNIQUE, NOT
NULL, CHECK and FOREIGN KEY constraints.
Whether the table is a
Every CREATE TABLE statement must specify a name for the new table.
Table names that begin with "sqlite_" are reserved for internal use. It
is an error to attempt to create a table with a name that starts with
"sqlite_".
If a schema-name is specified, it must be either "main",
"temp", or the name of an . In this case
the new table is created in the named database. If the "TEMP" or "TEMPORARY"
keyword occurs between the "CREATE" and "TABLE" then the new table is
created in the temp database. It is an error to specify both a
schema-name and the TEMP or TEMPORARY keyword, unless the
schema-name is "temp".
If no schema name is specified and the
TEMP keyword is not present then the table is created in the main
It is usually an error to attempt to create a new table in a database that
already contains a table, index or view of the same name. However, if the
"IF NOT EXISTS" clause is specified as part of the CREATE TABLE statement and
a table or view of the same name already exists, the CREATE TABLE command
simply has no effect (and no error message is returned). An error is still
returned if the table cannot be created because of an existing index, even
if the "IF NOT EXISTS" clause is specified.
It is not an error to create a table that has the same name as an
existing .
Tables are removed using the
statement.
CREATE TABLE ... AS SELECT Statements
A "CREATE TABLE ... AS SELECT" statement creates and populates a database
table based on the results of a SELECT statement. The table has the same
number of columns as the rows returned by the SELECT statement. The name of
each column is the same as the name of the corresponding column in the result
set of the SELECT statement. The declared type of each column is determined
of the corresponding expression in the result set
of the SELECT statement, as follows:
Expression Affinity
Column Declared Type
BLOB (a.k.a "NONE")
"" (empty string)
A table created using CREATE TABLE AS has no PRIMARY KEY and no
constraints of any kind. The default value of each column is NULL. The default
collation sequence for each column of the new table is BINARY.
Tables created using CREATE TABLE AS are initially populated with the
rows of data returned by the SELECT statement. Rows are assigned contiguously
values, starting with 1, in the
are returned by the SELECT statement.
Column Definitions
Unless it is a CREATE TABLE ... AS SELECT statement, a CREATE TABLE includes
one or more , optionally followed by a list of
Each column definition consists of the
name of the column, optionally followed by the declared type of the column,
then one or more optional . Included in
the definition of "column constraints" for the purposes of the previous
statement are the COLLATE and DEFAULT clauses, even though these are not really
constraints in the sense that they do not restrict the data that the table may
contain. The other constraints - NOT NULL, CHECK, UNIQUE, PRIMARY KEY and
FOREIGN KEY constraints - impose restrictions on the tables data, and are are
described under
Unlike most SQL databases, SQLite does not restrict the type of data that
may be inserted into a column based on the columns declared type. Instead,
SQLite uses . The declared type of a column is used to
determine the
of the column only.
The DEFAULT clause specifies a default value to use for the column if no
value is explicitly provided by the user when doing an . If there
is no explicit DEFAULT clause attached to a column definition, then the
default value of the column is NULL. An explicit DEFAULT clause may specify
that the default value is NULL, a string constant, a blob constant, a
signed-number, or any constant expression enclosed in parentheses. A
default value may also be one of the special case-independent keywords
CURRENT_TIME, CURRENT_DATE or CURRENT_TIMESTAMP. For the purposes of the
DEFAULT clause, an expression is considered constant if it does
contains no sub-queries, column or table references, ,
or string literals enclosed in double-quotes instead of single-quotes.
Each time a row is inserted into the table by an INSERT statement that
does not provide explicit values for all table columns the values stored in
the new row are determined by their default values, as follows:
If the default value of the column is a constant NULL, text, blob or
signed-number value, then that value is used directly in the new row.
If the default value of a column is an expression in parentheses, then
the expression is evaluated once for each row inserted and the results
used in the new row.
If the default value of a column is CURRENT_TIME, CURRENT_DATE or
CURRENT_TIMESTAMP, then the value used in the new row is a text
representation of the current UTC date and/or time. For CURRENT_TIME, the
format of the value is "HH:MM:SS". For CURRENT_DATE, "YYYY-MM-DD". The
format for CURRENT_TIMESTAMP is "YYYY-MM-DD HH:MM:SS".
The COLLATE clause specifies the name of a
the default collation sequence for the column. If no COLLATE clause is
specified, the default collation sequence is .
The number of columns in a table is limited by the
compile-time parameter. A single row of a table cannot store more than
bytes of data. Both of these limits can be lowered at
runtime using the
C/C++ interface.
SQL Data Constraints
Each table in SQLite may have at most one PRIMARY KEY. If the
keywords PRIMARY KEY are added to a column definition, then the primary key
for the table consists of that single column. Or, if a PRIMARY KEY clause
is specified as a , then the primary key of the table
consists of the list of columns specified as part of the PRIMARY KEY clause.
The PRIMARY KEY clause must contain only column names & the use of
expressions in an
of a PRIMARY KEY is not supported.
An error is raised if more than one PRIMARY KEY clause appears in a
CREATE TABLE statement.
The PRIMARY KEY is optional for ordinary tables
but is required for
If a table has a single column primary key and the declared type of that
column is "INTEGER" and the table is not a
then the column is known as an .
for a description of the special properties and behaviors
associated with an .
Each row in a table with a primary key must have a unique combination
of values in its primary key columns. For the purposes of determining
the uniqueness of primary key values, NULL values are considered distinct from
all other values, including other NULLs. If an
statement attempts to modify the table content so that two or more rows
have identical primary key values, that is a constraint violation.
According to the SQL standard, PRIMARY KEY should always imply NOT NULL.
Unfortunately, due to a bug in some early versions, this is not the
case in SQLite. Unless the column is an
the table is a
table or the column is declared NOT NULL,
SQLite allows NULL values in a PRIMARY KEY column.
SQLite could be fixed to
conform to the standard, but doing so might break legacy applications.
Hence, it has been decided to merely document the fact that SQLite
allowing NULLs in most PRIMARY KEY columns.
A UNIQUE constraint is similar to a PRIMARY KEY constraint, except
that a single table may have any number of UNIQUE constraints. For each
UNIQUE constraint on the table, each row must contain a unique combination
of values in the columns identified by the UNIQUE constraint.
For the purposes of UNIQUE constraints, NULL values
are considered distinct from all other values, including other NULLs.
As with PRIMARY KEYs, a UNIQUE
clause must contain
only column names & the use of
expressions in an
of a UNIQUE
is not supported.
In most cases, UNIQUE and PRIMARY KEY
constraints are implemented by creating a unique index in the database.
(The exceptions are
and PRIMARY KEYs on
Hence, the following schemas are logically equivalent:
CREATE TABLE t1(a, b UNIQUE);
CREATE TABLE t1(a, b PRIMARY KEY);
CREATE TABLE t1(a, b);
CREATE UNIQUE INDEX t1b ON t1(b);
A CHECK constraint may be attached to a column definition or
specified as a table constraint. In practice it makes no difference. Each
time a new row is inserted into the table or an existing row is updated,
the expression associated with each CHECK constraint is evaluated and
cast to a NUMERIC value in the same way as a . If the
result is zero (integer value 0 or real value 0.0), then a constraint
violation has occurred. If the CHECK expression evaluates to NULL, or
any other non-zero value, it is not a constraint violation.
The expression of a CHECK constraint may not contain a subquery.
A NOT NULL constraint may only be attached to a column definition,
not specified as a table constraint.
Not surprisingly, a NOT NULL
constraint dictates that the associated column may not contain a NULL value.
Attempting to set the column value to NULL when inserting a new row or
updating an existing one causes a constraint violation.
Exactly how a constraint violation is dealt with is determined by the
PRIMARY KEY, UNIQUE, NOT NULL and CHECK constraint has a default conflict
resolution algorithm. PRIMARY KEY, UNIQUE and NOT NULL constraints may be
explicitly assigned a default conflict resolution algorithm by including
in their definitions. Or, if a constraint definition
does not include a
or it is a CHECK constraint, the default
conflict resolution algorithm is ABORT. Different constraints within the
same table may have different default conflict resolution algorithms. See
the section titled
for additional information.
ROWIDs and the INTEGER PRIMARY KEY
Except for
tables, all rows within SQLite tables
have a 64-bit signed integer key that uniquely identifies the row within its table.
This integer is usually
called the "rowid". The rowid value can be accessed using one of the special
case-independent names "rowid", "oid", or "_rowid_" in place of a column name.
If a table contains a user defined column named "rowid", "oid" or "_rowid_",
then that name always refers the explicitly declared column and cannot be used
to retrieve the integer rowid value.
The rowid (and "oid" and "_rowid_") is omitted in
WITHOUT ROWID tables are only available in SQLite
() and later.
A table that lacks the WITHOUT ROWID clause is called a "rowid table".
The data for rowid tables is stored as a B-Tree structure containing
one entry for each table row, using the rowid value as the key. This means that
retrieving or sorting records by rowid is fast. Searching for a record with a
specific rowid, or for all records with rowids within a specified range is
around twice as fast as a similar search made by specifying any other PRIMARY
KEY or indexed value.
With one exception noted below, if a rowid table has a primary key that consists
of a single column and the declared type of that column is "INTEGER" in any mixture of
upper and lower case, then the column becomes an alias for the rowid. Such a
column is usually referred to as an "integer primary key". A PRIMARY KEY column
only becomes an integer primary key if the declared type name is exactly
"INTEGER".
Other integer type names like "INT" or "BIGINT" or "SHORT INTEGER"
or "UNSIGNED INTEGER" causes the primary key column to behave as an ordinary
table column with integer
and a unique index, not as an alias for
the rowid.
The exception mentioned above is that if the declaration of a column with
declared type "INTEGER" includes an "PRIMARY KEY DESC" clause, it does not
become an alias for the rowid and is not classified as an integer primary key.
This quirk is not by design. It is due to a bug in early versions of SQLite.
But fixing the bug could result in backwards incompatibilities.
Hence, the original behavior has been retained (and documented) because odd
behavior in a corner case is far better than a compatibility break.
This means
that the following three table declarations all cause the column "x" to be an
alias for the rowid (an integer primary key):
CREATE TABLE t(x INTEGER PRIMARY KEY ASC, y, z);
CREATE TABLE t(x INTEGER, y, z, PRIMARY KEY(x ASC));
CREATE TABLE t(x INTEGER, y, z, PRIMARY KEY(x DESC));
But the following declaration does not result in "x" being an alias for
the rowid:
CREATE TABLE t(x INTEGER PRIMARY KEY DESC, y, z);
Rowid values may be modified using an UPDATE statement in the same
way as any other column value can, either using one of the built-in aliases
("rowid", "oid" or "_rowid_") or by using an alias created by an integer
primary key. Similarly, an INSERT statement may provide a value to use as the
rowid for each row inserted. Unlike normal SQLite columns, an integer primary
key or rowid column must contain integer values. Integer primary key or rowid
columns are not able to hold floating point values, strings, BLOBs, or NULLs.
If an UPDATE statement attempts to set an integer primary key or rowid column
to a NULL or blob value, or to a string or real value that cannot be losslessly
converted to an integer, a "datatype mismatch" error occurs and the statement
is aborted. If an INSERT statement attempts to insert a blob value, or a string
or real value that cannot be losslessly converted to an integer into an
integer primary key or rowid column, a "datatype mismatch" error occurs and the
statement is aborted.
If an INSERT statement attempts to insert a NULL value into a rowid or
integer primary key column, the system chooses an integer value to use as the
rowid automatically. A detailed description of how this is done is provided
is not allowed to
use the rowid.
The parent key must used named columns only.SQLITE3数据库 一个表支持多少个字段？
[问题点数：40分，结帖人haosuai]
本版专家分：0
结帖率 100%
CSDN今日推荐
本版专家分：175059
2008年12月 其他数据库开发大版内专家分月排行榜第一2008年9月 其他数据库开发大版内专家分月排行榜第一
2014年7月 其他数据库开发大版内专家分月排行榜第二2014年3月 其他数据库开发大版内专家分月排行榜第二2013年7月 其他数据库开发大版内专家分月排行榜第二2013年4月 其他数据库开发大版内专家分月排行榜第二2012年3月 其他数据库开发大版内专家分月排行榜第二2011年8月 其他数据库开发大版内专家分月排行榜第二2011年7月 其他数据库开发大版内专家分月排行榜第二2009年11月 其他数据库开发大版内专家分月排行榜第二2009年7月 其他数据库开发大版内专家分月排行榜第二2009年6月 其他数据库开发大版内专家分月排行榜第二2009年5月 其他数据库开发大版内专家分月排行榜第二2009年4月 其他数据库开发大版内专家分月排行榜第二2009年3月 其他数据库开发大版内专家分月排行榜第二2009年1月 其他数据库开发大版内专家分月排行榜第二2008年10月 其他数据库开发大版内专家分月排行榜第二2008年8月 其他数据库开发大版内专家分月排行榜第二2003年9月 Delphi大版内专家分月排行榜第二
2014年4月 其他数据库开发大版内专家分月排行榜第三2013年10月 其他数据库开发大版内专家分月排行榜第三2013年9月 其他数据库开发大版内专家分月排行榜第三2013年6月 其他数据库开发大版内专家分月排行榜第三2012年12月 其他数据库开发大版内专家分月排行榜第三2012年11月 其他数据库开发大版内专家分月排行榜第三2012年10月 其他数据库开发大版内专家分月排行榜第三2012年9月 其他数据库开发大版内专家分月排行榜第三2012年1月 其他数据库开发大版内专家分月排行榜第三2011年11月 其他数据库开发大版内专家分月排行榜第三2011年9月 其他数据库开发大版内专家分月排行榜第三2011年6月 其他数据库开发大版内专家分月排行榜第三2011年5月 其他数据库开发大版内专家分月排行榜第三2011年4月 其他数据库开发大版内专家分月排行榜第三2011年3月 其他数据库开发大版内专家分月排行榜第三2010年11月 其他数据库开发大版内专家分月排行榜第三2010年4月 其他数据库开发大版内专家分月排行榜第三2010年1月 其他数据库开发大版内专家分月排行榜第三2009年12月 其他数据库开发大版内专家分月排行榜第三2009年2月 其他数据库开发大版内专家分月排行榜第三2008年7月 其他数据库开发大版内专家分月排行榜第三2008年6月 其他数据库开发大版内专家分月排行榜第三2008年1月 其他数据库开发大版内专家分月排行榜第三2007年12月 其他数据库开发大版内专家分月排行榜第三2003年12月 Delphi大版内专家分月排行榜第三2003年10月 Delphi大版内专家分月排行榜第三
本版专家分：0
本版专家分：175059
2008年12月 其他数据库开发大版内专家分月排行榜第一2008年9月 其他数据库开发大版内专家分月排行榜第一
2014年7月 其他数据库开发大版内专家分月排行榜第二2014年3月 其他数据库开发大版内专家分月排行榜第二2013年7月 其他数据库开发大版内专家分月排行榜第二2013年4月 其他数据库开发大版内专家分月排行榜第二2012年3月 其他数据库开发大版内专家分月排行榜第二2011年8月 其他数据库开发大版内专家分月排行榜第二2011年7月 其他数据库开发大版内专家分月排行榜第二2009年11月 其他数据库开发大版内专家分月排行榜第二2009年7月 其他数据库开发大版内专家分月排行榜第二2009年6月 其他数据库开发大版内专家分月排行榜第二2009年5月 其他数据库开发大版内专家分月排行榜第二2009年4月 其他数据库开发大版内专家分月排行榜第二2009年3月 其他数据库开发大版内专家分月排行榜第二2009年1月 其他数据库开发大版内专家分月排行榜第二2008年10月 其他数据库开发大版内专家分月排行榜第二2008年8月 其他数据库开发大版内专家分月排行榜第二2003年9月 Delphi大版内专家分月排行榜第二
2014年4月 其他数据库开发大版内专家分月排行榜第三2013年10月 其他数据库开发大版内专家分月排行榜第三2013年9月 其他数据库开发大版内专家分月排行榜第三2013年6月 其他数据库开发大版内专家分月排行榜第三2012年12月 其他数据库开发大版内专家分月排行榜第三2012年11月 其他数据库开发大版内专家分月排行榜第三2012年10月 其他数据库开发大版内专家分月排行榜第三2012年9月 其他数据库开发大版内专家分月排行榜第三2012年1月 其他数据库开发大版内专家分月排行榜第三2011年11月 其他数据库开发大版内专家分月排行榜第三2011年9月 其他数据库开发大版内专家分月排行榜第三2011年6月 其他数据库开发大版内专家分月排行榜第三2011年5月 其他数据库开发大版内专家分月排行榜第三2011年4月 其他数据库开发大版内专家分月排行榜第三2011年3月 其他数据库开发大版内专家分月排行榜第三2010年11月 其他数据库开发大版内专家分月排行榜第三2010年4月 其他数据库开发大版内专家分月排行榜第三2010年1月 其他数据库开发大版内专家分月排行榜第三2009年12月 其他数据库开发大版内专家分月排行榜第三2009年2月 其他数据库开发大版内专家分月排行榜第三2008年7月 其他数据库开发大版内专家分月排行榜第三2008年6月 其他数据库开发大版内专家分月排行榜第三2008年1月 其他数据库开发大版内专家分月排行榜第三2007年12月 其他数据库开发大版内专家分月排行榜第三2003年12月 Delphi大版内专家分月排行榜第三2003年10月 Delphi大版内专家分月排行榜第三
本版专家分：470998
2012年 荣获名人称号
2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
2013年 总版技术专家分年内排行榜第十2011年 总版技术专家分年内排行榜第七
本版专家分：0
本版专家分：175059
2008年12月 其他数据库开发大版内专家分月排行榜第一2008年9月 其他数据库开发大版内专家分月排行榜第一
2014年7月 其他数据库开发大版内专家分月排行榜第二2014年3月 其他数据库开发大版内专家分月排行榜第二2013年7月 其他数据库开发大版内专家分月排行榜第二2013年4月 其他数据库开发大版内专家分月排行榜第二2012年3月 其他数据库开发大版内专家分月排行榜第二2011年8月 其他数据库开发大版内专家分月排行榜第二2011年7月 其他数据库开发大版内专家分月排行榜第二2009年11月 其他数据库开发大版内专家分月排行榜第二2009年7月 其他数据库开发大版内专家分月排行榜第二2009年6月 其他数据库开发大版内专家分月排行榜第二2009年5月 其他数据库开发大版内专家分月排行榜第二2009年4月 其他数据库开发大版内专家分月排行榜第二2009年3月 其他数据库开发大版内专家分月排行榜第二2009年1月 其他数据库开发大版内专家分月排行榜第二2008年10月 其他数据库开发大版内专家分月排行榜第二2008年8月 其他数据库开发大版内专家分月排行榜第二2003年9月 Delphi大版内专家分月排行榜第二
2014年4月 其他数据库开发大版内专家分月排行榜第三2013年10月 其他数据库开发大版内专家分月排行榜第三2013年9月 其他数据库开发大版内专家分月排行榜第三2013年6月 其他数据库开发大版内专家分月排行榜第三2012年12月 其他数据库开发大版内专家分月排行榜第三2012年11月 其他数据库开发大版内专家分月排行榜第三2012年10月 其他数据库开发大版内专家分月排行榜第三2012年9月 其他数据库开发大版内专家分月排行榜第三2012年1月 其他数据库开发大版内专家分月排行榜第三2011年11月 其他数据库开发大版内专家分月排行榜第三2011年9月 其他数据库开发大版内专家分月排行榜第三2011年6月 其他数据库开发大版内专家分月排行榜第三2011年5月 其他数据库开发大版内专家分月排行榜第三2011年4月 其他数据库开发大版内专家分月排行榜第三2011年3月 其他数据库开发大版内专家分月排行榜第三2010年11月 其他数据库开发大版内专家分月排行榜第三2010年4月 其他数据库开发大版内专家分月排行榜第三2010年1月 其他数据库开发大版内专家分月排行榜第三2009年12月 其他数据库开发大版内专家分月排行榜第三2009年2月 其他数据库开发大版内专家分月排行榜第三2008年7月 其他数据库开发大版内专家分月排行榜第三2008年6月 其他数据库开发大版内专家分月排行榜第三2008年1月 其他数据库开发大版内专家分月排行榜第三2007年12月 其他数据库开发大版内专家分月排行榜第三2003年12月 Delphi大版内专家分月排行榜第三2003年10月 Delphi大版内专家分月排行榜第三
本版专家分：470998
2012年 荣获名人称号
2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
2013年 总版技术专家分年内排行榜第十2011年 总版技术专家分年内排行榜第七
本版专家分：0
本版专家分：0
本版专家分：470998
2012年 荣获名人称号
2010年 总版技术专家分年内排行榜第二
2009年 总版技术专家分年内排行榜第三
2013年 总版技术专家分年内排行榜第十2011年 总版技术专家分年内排行榜第七
匿名用户不能发表回复！
其他相关推荐
由于项目需求变更，我需要在sqlite数据库的表中删除一个字段，通用的sql操作语句如下：
[sql] view
plain copy
alter table rec
结果数据库提示如下错误：
搜索得知，原来SQLite目前还不支持drop column,所以必须想
1、支持多表连接，例如
select * from student,class
where student.cid=class.
2、支持左外连接(left outer join)
select * from foods
left outer join food_types
on foods.id=food_types.food_id
3、不支持右外连接和全
sqlite数据库中表、视图和触发器的基本信息存储在一张叫做sqlite_master的系统表中，所以要想统计有多少张表就要先学习sqlite_master表。
每一个sqlite数据库都有一张叫做sqlite_master的表，它定义数据库的模式。sqlite_master的表结构如下：
CREATE TABLE sqlite_master (
type TEXT,
需求：获取指定数据库的结构。包括数据库中的所有表和表的结构（即表名，字段名，字段类型等信息）
平台：vs2013+Qt
数据库驱动：sqlite
SQLite 仅仅支持 ALTER TABLE 语句的一部分功能，我们可以用 ALTER TABLE 语句来更改一个表的名字，也可向表中增加一个字段（列），但是我们不能删除一个已经存在的字段，或者更改一个已经存在的字段的名称、数据类型、限定符等等。
改变表名 - ALTER TABLE 旧表名 RENAME TO 新表名
增加一列 - ALTER TABLE 表
ret = sqlite3_get_table(datb,&select * from demoF&,&dbresult,&nrow,&ncolumn,&errmsg);上面那句在页表中有内容时可以查看页表的字段,不过页表中如果没有记录,上面那句就不能查看页表中的字段.不过下面这句可以查看(不管你的页表是否有内容)sprintf(sql,&PRAGMA table_...
sqlite查看所有表名及字段名
查询table，type 段是'table'，name段是table的名字, so:
select name from sqlite_master where type='table'
查询indices，type段是'index', name 是index的名字，tbl_name是index所拥有的table的名字
NSString *path = [[[NSBundle mainBundle] bundlePath] stringByAppendingPathComponent:@&branddb.sqlite&];
sqlite3_open([path UTF8String], &database);
sqlite3_stm
在sqlite中alter table 是无法实现对字段的添加或修改的
如：ALTER TABLE table_name ADD column_name datatype 这个语句在sqlite中无效
对于这问题，sqlite官方给出这样的解答，基本就是只能通过创建一张临时表，来修改字段
(11) How do I add or delete columns from an exis
获得查询结果表的列名：db = sqlite.connect('data.db')
cur = db.cursor()
cur.execute(&select * from table&)
col_name_list = [tuple[0] for tuple in cur.de}