-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Harish Vishwanath wrote:
> I would like to understand when sqlite generates an autoindex on primary keys
> of tables.
An autoindex is created when a column is unique since that is the only way
to know if a value being inserted is a duplicate of an
Hello,
I am using SQLite with Python (via SQLAlchemy). I would like to understand
when sqlite generates an autoindex on primary keys of tables. I am seeing
inconsistent behaviour in my case, where sqlite is automatically generating
indexes for some tables on their primary keys, but not all tables
>If all you have is a void*, you're going to have a very hard time calling
any sqlite3_bind_*() function.
yes, I just have all values with the type void*, so I can not choose which
sqlite3_bind_*() functions to use.
Jay A. Kreibich-2 wrote:
>
> On Thu, Feb 04, 2010 at 06:41:46PM -0800,
I have a query that runs very quickly and returns no results:
SELECT * FROM filebackup WHERE sha1='x';
However, the more restrictive query below runs very slowly, although
it obviously can't have any results either:
SELECT * FROM filebackup WHERE sha1='x' AND refid=0;
I have indexes on both
On Fri, Feb 05, 2010 at 12:54:30PM +1000, Mark Hessling scratched on the wall:
> I think the OP wanted to know how to find this programatically.
The .schema command runs a pretty simple query against sqlite_master.
Just look it up in shell.c... search for \"schema\".
Similar info (that is
On Thu, Feb 04, 2010 at 06:41:46PM -0800, gujx scratched on the wall:
>
> Maybe I didn't express the problem clearly.
> > e.g. if you have a text value, you use _text(), if you have an int, you
> > use _int()
> I just don't know what type I have,
If all you have is a void*, you're going to
I think the OP wanted to know how to find this programatically.
In that case see sqlite3_column_type() function call.
Cheers, Mark
On Fri, 2010-02-05 at 02:47 +, Simon Slavin wrote:
> On 5 Feb 2010, at 2:41am, gujx wrote:
>
> > Maybe I didn't express the problem clearly.
> >> e.g. if you
On 5 Feb 2010, at 2:41am, gujx wrote:
> Maybe I didn't express the problem clearly.
>> e.g. if you have a text value, you use _text(), if you have an int, you
>> use _int()
> I just don't know what type I have, so I want to get the meta type of the
> column somebody defined.
> e.g. I'd like to
Maybe I didn't express the problem clearly.
> e.g. if you have a text value, you use _text(), if you have an int, you
> use _int()
I just don't know what type I have, so I want to get the meta type of the
column somebody defined.
e.g. I'd like to use a bind routine to bind a variable t to a "?",
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
lizhe wrote:
> I am writing to enquire about a bug we found.
http://www.beiww.com/doc/oss/smart-questions.html
Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
您好:
我们使用的SQLITE3
数据库版本为3.6版本,在红帽编译器下运行,运行的硬件系统为LINUX(2.6版本),现在出现了一个问题,对有些板子,发现如果连续插入数据库会造成LINUX系统的崩溃,有的时候会造成FLASH的丢失,使用调试口测试,发现是堆栈益出,但是在有些板子上却很正常,可以连续插入几万条记录,请问这是什么原因造成的.
Dear Sir:
I am writing to enquire about a bug we found. Now the SQLITE3 database we
use is version 3.6, which
Not sure if this is intentional, but it looks like the wrong index is being
selected on fts tables when a rowid is involved.
Given a table:
CREATE VIRTUAL TABLE MessagesFts USING fts3(Message);
Explain query plan using sqlite 3.6.21:
sqlite> EXPLAIN QUERY PLAN SELECT * FROM MessagesFts WHERE
Pavel,
Thank you so much for your help. Your knowledge is worth
more than gold.
You were absolutely right regarding not closed blob handle!
(for prepare I use only sqlite3_prepare_v2)
I found out that I had one blob handle opened in the unrelated table in the
same database.
This handle was
I'm using FTS3 in a single table configuration:
CREATE VIRTUAL TABLE MessagesFts USING fts3(Message);
I have a writer thread that is writing messages to this table, as well as
several other tables, in batched transactions.
There are reader threads that may execute fts queries against the
> commit = 1;
> pStmt != NULL
> but
> sql = NULL; //under debugger: pStmt->isPrepareV2 = 0; pStmt->zSql = NULL;
So, I was right then that in case of not finished SELECT statement
autocommit will still be 1. But as you correctly noticed above
isPrepareV2 = 0 and it means that this statement
Thank you very much for your advice!
>to check that transaction
>wasn't committed yet you can connect to the database with external
>command while application is working and try to update or insert
>something. If it fails with message "The database file is locked" then
>application didn't
> 1) What else can prevent incremental data to be written to the hard drive?
Besides all that I mentioned only explicit BEGIN statement can open
transaction and thus prevent anything after that from being written to
disk immediately until COMMIT is executed. What you can do now is
first of all
Pavel,
Thank you very much for your email. I greatly appreciate
your knowledge on the internal workings of Sqlite and your kindness to share
it.
>All incremental writing is committed (and thus is written to disk)
>when blob handle is closed. And even when you close the handle
>transaction is
All incremental writing is committed (and thus is written to disk)
when blob handle is closed. And even when you close the handle
transaction is committed only when there's no more blob handles or
SELECT statements open at the moment on the same connection.
Pavel
On Wed, Feb 3, 2010 at 7:41 PM,
On Thu, Feb 04, 2010 at 03:59:14PM +0800, gujx scratched on the wall:
> There is a table like this:
> Is there any way to resolve this?
First off, you need to understand that columns do not have "types",
they have affinities.
http://sqlite.org/datatype3.html
Read this whole page.
There is a table like this:
id(varchar)
name(text)
age(integer)
ss(text)
Its name is “test_for_cpp”, now I get the pointer of sqlite successfully.
There are codes below:
sqlite3_stmt *ppStmt;
const char *pzTail;
int nVal = sqlite3_prepare_v2(
conn,
21 matches
Mail list logo
