[sqlite] Question about sqlite3_extended_result_codes()
Hello,
I have a couple questions about sqlite3_extended_result_codes():
1) Once I enable it, is it possible to determine whether extended
result codes is enabled for a given a sqlite3* handle?
2) Do I have to process each result code in order to obtain the
"regular" SQLite code, or can I compare it directly? For example:
// assume db is valid...
int resultCode = sqlite3_exec(db, ..., );
if (resultCode == SQLITE_OK) {
// do something...
}
3) Are the extended results returned *only* when SQLITE_IOERR is
detected? How does it work?
Thanks for the help,
-- Tito
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Feeds for sqlite releases
On Jun 27, 2009, at 6:49 PM, João Eiras wrote: > Hi ! > > I really missing having feeds to track sqlite releases. Currently I > either have to go through the mailing list, which is not low > traffic, or open the website. > Would you consider having an rss feed for sqlite releases ? There is the sqlite-annou...@sqlite.org mailing list. Much lower traffic - basically just announcements of releases. D. Richard Hipp d...@hwaci.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Feeds for sqlite releases
João Eiras wrote: > I really missing having feeds to track sqlite releases. Currently I > either have to go through the mailing list, which is not low traffic, > or open the website. Would you consider having an rss feed for sqlite > releases ? See if this helps: http://www.sqlite.org/cvstrac/timeline.rss Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Feeds for sqlite releases
Hi, there already is an RSS feed - http://www.sqlite.org/cvstrac/timeline.rss - unfortunately it can't be limited to display only the milestones as regular web timeline can. Best regards, Filip Navara On Sun, Jun 28, 2009 at 12:49 AM, João Eiras wrote: > Hi ! > > I really missing having feeds to track sqlite releases. Currently I either > have to go through the mailing list, which is not low traffic, or open the > website. > Would you consider having an rss feed for sqlite releases ? > > Thanks. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] first few characters of varchar() corrupted when SELECTing from a C++ program?
uralmaza...@pop3.ru wrote: > sqlite3_open_v2( "testdat", &sqlDB, SQLITE_OPEN_READWRITE | > SQLITE_OPEN_CREATE, NULL ); > sqlite3_prepare_v2( sqlDB, "SELECT b FROM whee WHERE a='bing';", -1, > &sqlStat, NULL ); > sqlite3_step( sqlStat ); > const unsigned char *testValue = sqlite3_column_text( sqlStat, 0 ); > > both a and b are varchar(20)s > > calling the query from the command-line tool returns the proper > result "bang", however, running this code the value testValue shows > up as " " Shows up where? How do you examine the string? Are you examining testValue immediately after sqlite3_column_text call? sqlite3_column_text returns a pointer to an internal buffer that may be reused by many other calls. If you need to keep the string around for later use, you must make a copy of it right after sqlite3_column_text. Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Feeds for sqlite releases
Hi ! I really missing having feeds to track sqlite releases. Currently I either have to go through the mailing list, which is not low traffic, or open the website. Would you consider having an rss feed for sqlite releases ? Thanks. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] first few characters of varchar( ) corrupted when SELECTing from a C++ p rogram?
Greetings, maybe it's just me being stupid, I'll best jump right to the code: sqlite3_open_v2( "testdat", &sqlDB, SQLITE_OPEN_READWRITE | SQLITE_OPEN_CREATE, NULL ); sqlite3_prepare_v2( sqlDB, "SELECT b FROM whee WHERE a='bing';", -1, &sqlStat, NULL ); sqlite3_step( sqlStat ); const unsigned char *testValue = sqlite3_column_text( sqlStat, 0 ); both a and b are varchar(20)s calling the query from the command-line tool returns the proper result "bang", however, running this code the value testValue shows up as " " for longer strings only the first four characters are corrupted, and the rest reads okay, what am I doing wrong? ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] very large SQLite tables
I have actually implemented such a structure, and it worked well. Kosenko Max wrote: > You're talking about db size much less than 1 billion records. > > In 1 billion records db with described scenario cache hit ratio so small > that everything you're talking about just very close to zero difference in > effect. Because 1 uncached random IO operation is 10ms. Any reasonable > calculations (in the current scenario) or even saving new page near current > page far less than 10ms. > > And that's what I've said - that proposal won't help and will make things a > bit worse and more complex. > > In future, when we all will forget 100 IOPS wall and will be hitting 100K-1M > IOPS, your assumptions might become in place with large DB. But I'm sure - > tricks like splitting table into 100-1 tables with hash wheel in mind > won't give any additional significant benefit. Hashtables can be faster in > case you don't need range operations, but placing hash on top of B-Tree to > eleminate single b-tree page shouldn't give any speedup. > > If you have proven that this trick still works - I will be glad to see code > sample with benchmarks. > > Thanks. > Max. > > > John Stanton-3 wrote: > >> Quite wrong. Searching a B-Tree is relatively inexpensive but node >> splits are expensive. >> >> Inserting a non-terminal key in a part filled leaf node is cheap, >> inserting a terminal key is more expensive and a split is more expensive >> again >> >> The reason we spend the extra resources maintaining B-tree indices is >> because they maintain the keys in sorted sequence. If maintaining keys >> in order is not required a hashing method can be faster. >> >> Our fastest B-Tree indices use the virtual memory capability of the OS >> as cache and perform very well.by avoiding buffer shadowing and >> maximizing utilization of physical memory.. >> ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] SQLite version 3.6.16
SQLite version 3.6.16 is now available on the SQLite website: http://www.sqlite.org/ Version 3.6.16 is a regular monthly maintenance release. Curiously, even though it is released at the end of June, version 3.6.16 is considered the monthly maintenance release for July. We have accelerated the release of 3.6.16 in order to get the fix for ticket #3929 into circulation as quickly as possible. The bug in ticket #3929 can cause problems for applications that use AFTER triggers to update the same table that the trigger is attached to. See http://www.sqlite.org/cvstrac/tktview?tn=3929 for additional information. Because of ticket #3929, upgrading from version 3.6.15 is recommended. Nevertheless, applications that do not use self-referential AFTER triggers (which is to say, most applications) can continue using 3.6.15 safely. As always, please let me know if you encounter any problems with the new release. D. Richard Hipp d...@hwaci.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] New-B
THANKS MAN! On Sat, Jun 27, 2009 at 10:14 AM, P Kishor wrote: > On Sat, Jun 27, 2009 at 10:03 AM, Jamiil Abd Al Qadir > wrote: > > Hey kids! > > I wanted to know if there is a tutorial of how to create new database > > tables, sort tables, etc., etc. > > > .. > > Its called Google. It opens doors to all kinds of tutorials. You can > also try your luck with Bing. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Happiness has many doors, and when one of them closes another opens, yet we spent so much time looking at the one that is shut that we don't see the one that just opened.. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to write the string "1.0" into a database table
I am really sorry, The correct code is given below:
//
#include
#include
#include
#include
#include
const char *create_and_insert = "create table some_tbl (id int primary
key, version text check (version in (\"1.0\")));"
"insert into some_tbl (id) values (1);";
const char *update_sql = "update some_tbl set version = ? where id = ?";
int32_t main(int32_t argc, char *argv[])
{
sqlite3 *db;
char *err_msg;
sqlite3_stmt *stmt;
int32_t ret;
if (argc != 2) {
fprintf(stderr, "Usage: %s .\n", argv[0]);
goto out1;
}
db = NULL;
ret = sqlite3_open(argv[1], &db);
if (ret != SQLITE_OK) {
fprintf(stderr, "Unable to open database.\n");
goto out1;
}
err_msg = NULL;
ret = sqlite3_exec(db, create_and_insert, NULL, NULL, &err_msg);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_exec: %s.\n", err_msg);
sqlite3_free(err_msg);
}
stmt = NULL;
ret = sqlite3_prepare_v2(db, update_sql, strlen(update_sql) + 1,
&stmt, NULL);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_stmt: %s", sqlite3_errmsg(db));
goto out2;
}
/* The second argument indicates the posistion of the column */
ret = sqlite3_bind_text(stmt, 1, "1.0", strlen("1.0") + 1,
SQLITE_TRANSIENT);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_bind_text: %s",
sqlite3_errmsg(db));
goto out3;
}
ret = sqlite3_bind_int(stmt, 2, 0);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_bind_int: %s",
sqlite3_errmsg(db));
goto out3;
}
ret = sqlite3_step(stmt);
if (ret != SQLITE_DONE) {
fprintf(stderr, "sqlite3_step: %s",
sqlite3_errmsg(db));
goto out3;
}
ret = sqlite3_finalize(stmt);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_finalize: %s",
sqlite3_errmsg(db));
}
ret = sqlite3_close(db);
if (ret != SQLITE_OK) {
fprintf(stderr, "Unable to close the database.\n");
}
exit(0);
out3:
ret = sqlite3_finalize(stmt);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_finalize: %s",
sqlite3_errmsg(db));
}
out2:
ret = sqlite3_close(db);
out1:
exit(1);
}
/*/
Simon Slavin wrote:
> On 27 Jun 2009, at 8:47am, chandan wrote:
>
>
>> const char *create_and_insert = "create table some_tbl (id int primary
>> key, version text check (version in (\"1.0\")));"
>>"insert into some_tbl (id) values (1);";
>> const char *update_sql = "update some_tbl set version = ? where id
>> = ?";
>>
>
> I note you then do
>
> ret = sqlite3_bind_int(stmt, 2, 0);
>
> doesn't this look for id=2 ?
>
>
>
>
> To diagnose your problem, first try the whole thing as text: execute
> the command
>
> update some_tbl set version = '1.0' where id = 1
>
> and see if it works. If it doesn't, try it in sqlite3 command-line
> tool and see if that works.
>
> Simon.
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] New-B
On Sat, Jun 27, 2009 at 10:03 AM, Jamiil Abd Al Qadir wrote: > Hey kids! > I wanted to know if there is a tutorial of how to create new database > tables, sort tables, etc., etc. > .. Its called Google. It opens doors to all kinds of tutorials. You can also try your luck with Bing. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] New-B
Hey kids! I wanted to know if there is a tutorial of how to create new database tables, sort tables, etc., etc. TIA -- Happiness has many doors, and when one of them closes another opens, yet we spent so much time looking at the one that is shut that we don't see the one that just opened.. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] very large SQLite tables
You're talking about db size much less than 1 billion records. In 1 billion records db with described scenario cache hit ratio so small that everything you're talking about just very close to zero difference in effect. Because 1 uncached random IO operation is 10ms. Any reasonable calculations (in the current scenario) or even saving new page near current page far less than 10ms. And that's what I've said - that proposal won't help and will make things a bit worse and more complex. In future, when we all will forget 100 IOPS wall and will be hitting 100K-1M IOPS, your assumptions might become in place with large DB. But I'm sure - tricks like splitting table into 100-1 tables with hash wheel in mind won't give any additional significant benefit. Hashtables can be faster in case you don't need range operations, but placing hash on top of B-Tree to eleminate single b-tree page shouldn't give any speedup. If you have proven that this trick still works - I will be glad to see code sample with benchmarks. Thanks. Max. John Stanton-3 wrote: > > Quite wrong. Searching a B-Tree is relatively inexpensive but node > splits are expensive. > > Inserting a non-terminal key in a part filled leaf node is cheap, > inserting a terminal key is more expensive and a split is more expensive > again > > The reason we spend the extra resources maintaining B-tree indices is > because they maintain the keys in sorted sequence. If maintaining keys > in order is not required a hashing method can be faster. > > Our fastest B-Tree indices use the virtual memory capability of the OS > as cache and perform very well.by avoiding buffer shadowing and > maximizing utilization of physical memory.. -- View this message in context: http://www.nabble.com/very-large-SQLite-tables-tp24201098p24233133.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to write the string "1.0" into a database table
On 27 Jun 2009, at 8:47am, chandan wrote: > const char *create_and_insert = "create table some_tbl (id int primary > key, version text check (version in (\"1.0\")));" >"insert into some_tbl (id) values (1);"; > const char *update_sql = "update some_tbl set version = ? where id > = ?"; I note you then do ret = sqlite3_bind_int(stmt, 2, 0); doesn't this look for id=2 ? To diagnose your problem, first try the whole thing as text: execute the command update some_tbl set version = '1.0' where id = 1 and see if it works. If it doesn't, try it in sqlite3 command-line tool and see if that works. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] How to find the version of the database.
On 27/06/2009 3:36 AM, Kalyani Phadke wrote:
> Is there any way to find the version of SQlite3 database. eg. I have
> test.DB file . I want to know which SQLite3 version its using ..eg 3.5.4
> or 3.6.15?
Short answer: You can't know. What problem do you face that makes you
want to know? If the problem is "I need to know the earliest version of
SQLite3 that can be used to access test.db"
Long answer:
Assuming the database has been created/updated by version X of the
library and you attempt to open the database with version Y of the library:
if Y < X
and X used some new feature that Y doesn't know about:
Y won't access the database
Q: How does Y know what X did?
A: X records the most recent feature-set that it used in bytes 44..47 of
the database header; see
http://www.sqlite.org/fileformat.html#database_header
From the number you find there (should be one of 1, 2, 3, 4) you can
infer some but not much information about what versions have been
updating the database. Note: either of those two versions that you
mention could have been updating the database, but if neither used any
new features, the magic number would be 1 on both cases. The magic
number ("Schema layer file-format") is in effect a file-format version
number. This may well be what you need -- there seems to be no way of
getting this number short of opening the database as a file however you
can and digging it out.
HTH,
John
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] very large SQLite tables
Quite wrong. Searching a B-Tree is relatively inexpensive but node splits are expensive. Inserting a non-terminal key in a part filled leaf node is cheap, inserting a terminal key is more expensive and a split is more expensive again The reason we spend the extra resources maintaining B-tree indices is because they maintain the keys in sorted sequence. If maintaining keys in order is not required a hashing method can be faster. Our fastest B-Tree indices use the virtual memory capability of the OS as cache and perform very well.by avoiding buffer shadowing and maximizing utilization of physical memory.. Kosenko Max wrote: > Expenses in B-Tree not in the node splitting (that is really not that often > and takes small amount of time). As I've said - it's in finding right place > to insert. > > Root level which takes 1 page will do the same as your hash index. And will > use much less space in cache. This root page in such DB will always be in > cache. So you won't gain any advantage at all. And multi-threading also > won't use the benefit of multiply tables. At least in SQLite. > > That method called partitioning. It gives advantages when partitions divided > by some logic and there is a high chance to hit fewer partitions in average. > It also can benefit a bit in case RDBMS supports real parallel execution and > you have a lot of hard drives. That is not the case with SQLite (well you > can compile without thread safety and try to do own locks). > > I have actually posted a real proposal to make DB much faster. That will > work. > Proposal with 100 tables as a hash buckets doesn't works and I've checked > that a lot of time ago. > You have a sample where it works and gives any visible benefit? I'd like to > see that. > > My another addition to proposal is to use SSD with as small as possible > average access time. Some of them can easily do 50-100x faster. And that > will give 20-50x times faster inserts. > > Thank you. > Max. > > > John Stanton-3 wrote: > >> This technique is used extensively in disk cacheing and in maintaining >> file directories with huge numbers of files.. >> >> I would expect it toincrease key insertion speed because it removes a >> level of index in the B-tree of each index. The expensive activity in a >> B-tree index insertion is a node split which requires that key >> information be updated in each internal node level and possibly a new >> level added. Fewer levels mean faster performance. >> >> This method could also be used to add parallelism by having multiple >> threads or processes perform insertions concurrently. Having each >> database in a separate databases would help this approach. >> It would also help with concurrent read accesses. >> >> If this application only has one table and does not need SQL then there >> are better solutions than using Sqlite and paying the price for its many >> features but not using them. >> > > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] very large SQLite tables
Expenses in B-Tree not in the node splitting (that is really not that often and takes small amount of time). As I've said - it's in finding right place to insert. Root level which takes 1 page will do the same as your hash index. And will use much less space in cache. This root page in such DB will always be in cache. So you won't gain any advantage at all. And multi-threading also won't use the benefit of multiply tables. At least in SQLite. That method called partitioning. It gives advantages when partitions divided by some logic and there is a high chance to hit fewer partitions in average. It also can benefit a bit in case RDBMS supports real parallel execution and you have a lot of hard drives. That is not the case with SQLite (well you can compile without thread safety and try to do own locks). I have actually posted a real proposal to make DB much faster. That will work. Proposal with 100 tables as a hash buckets doesn't works and I've checked that a lot of time ago. You have a sample where it works and gives any visible benefit? I'd like to see that. My another addition to proposal is to use SSD with as small as possible average access time. Some of them can easily do 50-100x faster. And that will give 20-50x times faster inserts. Thank you. Max. John Stanton-3 wrote: > This technique is used extensively in disk cacheing and in maintaining > file directories with huge numbers of files.. > > I would expect it toincrease key insertion speed because it removes a > level of index in the B-tree of each index. The expensive activity in a > B-tree index insertion is a node split which requires that key > information be updated in each internal node level and possibly a new > level added. Fewer levels mean faster performance. > > This method could also be used to add parallelism by having multiple > threads or processes perform insertions concurrently. Having each > database in a separate databases would help this approach. > It would also help with concurrent read accesses. > > If this application only has one table and does not need SQL then there > are better solutions than using Sqlite and paying the price for its many > features but not using them. -- View this message in context: http://www.nabble.com/very-large-SQLite-tables-tp24201098p24231750.html Sent from the SQLite mailing list archive at Nabble.com. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to write the string "1.0" into a database table
On Jun 27, 2009, at 2:47 PM, chandan wrote:
> The code snippet is shown below:
>
> /
> **/
> #include
> #include
> #include
> #include
> #include
>
> const char *create_and_insert = "create table some_tbl (id int primary
> key, version text check (version in (\"1.0\")));"
>"insert into some_tbl (id) values (1);";
> const char *update_sql = "update some_tbl set version = ? where id
> = ?";
>
> int32_t main(int32_t argc, char *argv[])
> {
>sqlite3 *db;
>char *err_msg;
>sqlite3_stmt *stmt;
>int32_t ret;
>
>if (argc != 2) {
>fprintf(stderr, "Usage: %s .\n", argv[0]);
>goto out1;
>}
>
>db = NULL;
>ret = sqlite3_open(argv[1], &db);
>if (ret != SQLITE_OK) {
>fprintf(stderr, "Unable to open database.\n");
>goto out1;
>}
>
>err_msg = NULL;
>ret = sqlite3_exec(db, create_and_insert, NULL, NULL, &err_msg);
>if (ret != SQLITE_OK) {
>fprintf(stderr, "sqlite3_exec: %s.\n", err_msg);
>sqlite3_free(err_msg);
>}
>
>stmt = NULL;
>ret = sqlite3_prepare_v2(db, update_sql, strlen(update_sql) + 1,
> &stmt, NULL);
>if (ret != SQLITE_OK) {
>fprintf(stderr, "sqlite3_stmt: %s", sqlite3_errmsg(db));
>goto out2;
>}
>
>ret = sqlite3_bind_text(stmt, 1, "1.1", strlen("1.1") + 1,
>SQLITE_TRANSIENT);
>if (ret != SQLITE_OK) {
>fprintf(stderr, "sqlite3_bind_text: %s",
>sqlite3_errmsg(db));
>goto out3;
>}
>
>ret = sqlite3_bind_int(stmt, 2, 0);
The 0 above should be 1. Also, you don't need to add one to the
return of strlen().
Dan.
>
>if (ret != SQLITE_OK) {
>fprintf(stderr, "sqlite3_bind_int: %s",
>sqlite3_errmsg(db));
>goto out3;
>}
>
>ret = sqlite3_step(stmt);
>if (ret != SQLITE_DONE) {
>fprintf(stderr, "sqlite3_step: %s",
>sqlite3_errmsg(db));
>goto out3;
>}
>
>ret = sqlite3_finalize(stmt);
>if (ret != SQLITE_OK) {
>fprintf(stderr, "sqlite3_finalize: %s",
>sqlite3_errmsg(db));
>}
>
>ret = sqlite3_close(db);
>if (ret != SQLITE_OK) {
>fprintf(stderr, "Unable to close the database.\n");
>}
>
>exit(0);
>
> out3:
>ret = sqlite3_finalize(stmt);
>if (ret != SQLITE_OK) {
>fprintf(stderr, "sqlite3_finalize: %s",
>sqlite3_errmsg(db));
>}
> out2:
>ret = sqlite3_close(db);
> out1:
>exit(1);
> }
> /
> /
>
>
> Roger Binns wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> chandan wrote:
>>
>>> I have attached the C program along this mail.
>>>
>>
>> This mailing list strips all attachments, so we can't see your
>> code :-)
>>
>>
>>> Am i doing anything wrong in the program?
>>>
>>
>> Yes. SQLite does fundamentally work. We'd have noticed by now if a
>> simple update didn't work :-)
>>
>> You should look over the programming documentation on the web site
>> including sample programs again.
>>
>> Roger
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (GNU/Linux)
>>
>> iEYEARECAAYFAkpF0O4ACgkQmOOfHg372QQlrQCffy0JJqpxSaDR8pg9B903eofi
>> DYYAnR/gOPJLgpdC1c0CLwa0rA7IOJG0
>> =MP0E
>> -END PGP SIGNATURE-
>> ___
>> sqlite-users mailing list
>> sqlite-users@sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] very large SQLite tables
This technique is used extensively in disk cacheing and in maintaining file directories with huge numbers of files.. I would expect it toincrease key insertion speed because it removes a level of index in the B-tree of each index. The expensive activity in a B-tree index insertion is a node split which requires that key information be updated in each internal node level and possibly a new level added. Fewer levels mean faster performance. This method could also be used to add parallelism by having multiple threads or processes perform insertions concurrently. Having each database in a separate databases would help this approach. It would also help with concurrent read accesses. If this application only has one table and does not need SQL then there are better solutions than using Sqlite and paying the price for its many features but not using them. Kosenko Max wrote: > John Stanton-3 wrote: > >> Why would it not work? It is just adding an extra top level to the >> index. A tried and true method. >> > > It will work. But won't give performance benefit. And from my undestanding > it will even slow down things. > You can place parts of index in different DB and on different HDD thinking > it will boost the performance. > > But the problem is that we aren't talking about multiply selects at the same > time... We are talking about updating index in sqlite which is > single-threaded and even under load that wouldn't give you any advantages. > > Moreover you're emulating part of B-Tree with that approach and making it > slower and more space consumptive. So should it work as a solution? No. > > You have an idea why it should work? Tell me so. > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to write the string "1.0" into a database table
The code snippet is shown below:
/**/
#include
#include
#include
#include
#include
const char *create_and_insert = "create table some_tbl (id int primary
key, version text check (version in (\"1.0\")));"
"insert into some_tbl (id) values (1);";
const char *update_sql = "update some_tbl set version = ? where id = ?";
int32_t main(int32_t argc, char *argv[])
{
sqlite3 *db;
char *err_msg;
sqlite3_stmt *stmt;
int32_t ret;
if (argc != 2) {
fprintf(stderr, "Usage: %s .\n", argv[0]);
goto out1;
}
db = NULL;
ret = sqlite3_open(argv[1], &db);
if (ret != SQLITE_OK) {
fprintf(stderr, "Unable to open database.\n");
goto out1;
}
err_msg = NULL;
ret = sqlite3_exec(db, create_and_insert, NULL, NULL, &err_msg);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_exec: %s.\n", err_msg);
sqlite3_free(err_msg);
}
stmt = NULL;
ret = sqlite3_prepare_v2(db, update_sql, strlen(update_sql) + 1,
&stmt, NULL);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_stmt: %s", sqlite3_errmsg(db));
goto out2;
}
ret = sqlite3_bind_text(stmt, 1, "1.1", strlen("1.1") + 1,
SQLITE_TRANSIENT);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_bind_text: %s",
sqlite3_errmsg(db));
goto out3;
}
ret = sqlite3_bind_int(stmt, 2, 0);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_bind_int: %s",
sqlite3_errmsg(db));
goto out3;
}
ret = sqlite3_step(stmt);
if (ret != SQLITE_DONE) {
fprintf(stderr, "sqlite3_step: %s",
sqlite3_errmsg(db));
goto out3;
}
ret = sqlite3_finalize(stmt);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_finalize: %s",
sqlite3_errmsg(db));
}
ret = sqlite3_close(db);
if (ret != SQLITE_OK) {
fprintf(stderr, "Unable to close the database.\n");
}
exit(0);
out3:
ret = sqlite3_finalize(stmt);
if (ret != SQLITE_OK) {
fprintf(stderr, "sqlite3_finalize: %s",
sqlite3_errmsg(db));
}
out2:
ret = sqlite3_close(db);
out1:
exit(1);
}
//
Roger Binns wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> chandan wrote:
>
>>I have attached the C program along this mail.
>>
>
> This mailing list strips all attachments, so we can't see your code :-)
>
>
>> Am i doing anything wrong in the program?
>>
>
> Yes. SQLite does fundamentally work. We'd have noticed by now if a
> simple update didn't work :-)
>
> You should look over the programming documentation on the web site
> including sample programs again.
>
> Roger
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkpF0O4ACgkQmOOfHg372QQlrQCffy0JJqpxSaDR8pg9B903eofi
> DYYAnR/gOPJLgpdC1c0CLwa0rA7IOJG0
> =MP0E
> -END PGP SIGNATURE-
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] unable to write the string "1.0" into a database table
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 chandan wrote: >I have attached the C program along this mail. This mailing list strips all attachments, so we can't see your code :-) > Am i doing anything wrong in the program? Yes. SQLite does fundamentally work. We'd have noticed by now if a simple update didn't work :-) You should look over the programming documentation on the web site including sample programs again. Roger -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpF0O4ACgkQmOOfHg372QQlrQCffy0JJqpxSaDR8pg9B903eofi DYYAnR/gOPJLgpdC1c0CLwa0rA7IOJG0 =MP0E -END PGP SIGNATURE- ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
