Re: [sqlite] Is there any memory leak in the code while being busy?

the code's test result in my first post is : pthread2: prepare: 0, p_stmt: 0xb6a00de0, errmsg: not an error pthread2: step: 5, p_stmt: 0xb6a00de0, errmsg: database is locked pthread2: finalize: 5, p_stmt: 0xb6a00de0, errmsg: database is locked pthread2: finalize: 21, p_stmt:

Re: [sqlite] Is there any memory leak in the code while being busy?

Thanks :) But in my real code, the sqlite3_free(sql) is in the right place. So I think that there are other reasons causing the leak. Black, Michael (IS) wrote: > > You need to sqlite3_free(sql) after you use the sql from your > sqlite3_mprintf(). > > sql = sqlite3_mprintf

Re: [sqlite] Last 3 items per ID

Thanks; yes, that works. Will need to add maybe a compound index to make it faster. RBS On Fri, Apr 23, 2010 at 11:38 PM, Igor Tandetnik wrote: > Bart Smissaert wrote: >> Simplified there is a table like this: >> >> create table xxx( >>    [entry_id] integer primary_key,

Re: [sqlite] Last 3 items per ID

Bart Smissaert wrote: > Simplified there is a table like this: > > create table xxx( >[entry_id] integer primary_key, >[person_id] integer) > > Now I need to retrieve the rows with the 3 highest entry_id numbers > for each person_id. select * from xxx t1 where rowid in ( select rowid

Re: [sqlite] Last 3 items per ID

Yes, that is the best I could come up with. Thanks for confirming that there is nothing better. RBS On Fri, Apr 23, 2010 at 11:18 PM, Pavel Ivanov wrote: >> Can I do this in SQL or do I need to do this in my application? > > You cannot do that with pure standard SQL. Some

Re: [sqlite] Last 3 items per ID

> Can I do this in SQL or do I need to do this in my application? You cannot do that with pure standard SQL. Some other RDBMS added support for such things into their SQL dialect, but not SQLite. You can pretty easily do this in your application by querying all person_id first: select distinct

Re: [sqlite] Last 3 items per ID

On 23 Apr 2010, at 11:03pm, Bart Smissaert wrote: > there is a table like this: > > create table xxx( >[entry_id] integer primary_key, >[person_id] integer) > > Now I need to retrieve the rows with the 3 highest entry_id numbers > for each person_id. I can't think of a way to do it

[sqlite] Last 3 items per ID

Simplified there is a table like this: create table xxx( [entry_id] integer primary_key, [person_id] integer) Now I need to retrieve the rows with the 3 highest entry_id numbers for each person_id. so for example (in reality entry_id can have gaps): entry_id person_id

Re: [sqlite] column output truncating

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2010 08:42 AM, Derek Martin wrote: > It would be swell if sqlite3 had a -notruncate option or some such, You do know that the code is public domain, so you can copy it, modify it, redistribute it, use it to take over the world, charge for it

Re: [sqlite] column output truncating

On Fri, Apr 23, 2010 at 05:43:21PM +0100, Simon Davies wrote: > Pick the right width for the columns as per the following [...] Thanks, this might be helpful. -- Derek Martin Software Quality Assurance Engineer Akamai Technologies demar...@akamai.com

Re: [sqlite] column output truncating

On Fri, Apr 23, 2010 at 11:04:01AM -0500, P Kishor wrote: > On Fri, Apr 23, 2010 at 10:42 AM, Derek Martin wrote: > > Column mode (without any truncation) is the format desired for these > > reports...  Picking large enough values is bad, because it means that > > I'd need to

Re: [sqlite] column output truncating

On 23 April 2010 16:42, Derek Martin wrote: > On Fri, Apr 23, 2010 at 08:52:37AM -0500, Jay A. Kreibich wrote: >> On Thu, Apr 22, 2010 at 06:31:07PM -0400, Derek Martin scratched on the wall: >> > Hi, > > Sadly that was the conclusion I had reached before asking here. >

Re: [sqlite] column output truncating

On 23 Apr 2010, at 4:42pm, Derek Martin wrote: > It would be swell if sqlite3 had a -notruncate option or some such, > though adding one now wouldn't really solve my immediate problem, > since that wouldn't be available on our desktop image. With its > current behavior, column mode seems fairly

Re: [sqlite] column output truncating

On Fri, Apr 23, 2010 at 10:42 AM, Derek Martin wrote: > On Fri, Apr 23, 2010 at 08:52:37AM -0500, Jay A. Kreibich wrote: >> On Thu, Apr 22, 2010 at 06:31:07PM -0400, Derek Martin scratched on the wall: >> > Hi, >> > >> > I have a query that produces about 10 columns, some of

Re: [sqlite] column output truncating

On Fri, Apr 23, 2010 at 08:52:37AM -0500, Jay A. Kreibich wrote: > On Thu, Apr 22, 2010 at 06:31:07PM -0400, Derek Martin scratched on the wall: > > Hi, > > > > I have a query that produces about 10 columns, some of which are very > > wide. When I run sqlite3 with -column -header, it truncates

Re: [sqlite] Fw: SQLite and Windows 7

> Hello, > > in the near future we will implement windows 7. My question: Is > SQLite running on windows 7? I have been running an older version of SQLite on Windows 7 ever since RTM back in August of last year. The only issue I would see you having is if the host application does not have write

Re: [sqlite] Fw: SQLite and Windows 7

>> in the near future we will implement windows 7. My question: Is >> SQLite running on windows 7? >> I have been using sqlite under windows 7 for at least 8 months without a single issue. John ___ sqlite-users mailing list sqlite-users@sqlite.org

[sqlite] Fw: SQLite and Windows 7

> Hello, > > in the near future we will implement windows 7. My question: Is > SQLite running on windows 7? > > > I´am glad about your quick response. > > Thanks in advance. > > > > !! Bitte beachten Sie meine neue Mailadresse / Please note my new > mail address > > Freundliche Grüße / Regards

Re: [sqlite] column output truncating

On Thu, Apr 22, 2010 at 06:31:07PM -0400, Derek Martin scratched on the wall: > Hi, > > I have a query that produces about 10 columns, some of which are very > wide. When I run sqlite3 with -column -header, it truncates all > fields to 10 characters. This makes the query absolutely useless. >

Re: [sqlite] column output truncating

On Fri, Apr 23, 2010 at 8:39 AM, Adam DeVita wrote: > Could you include a bit more information about your post? (Version number, > operating system etc.) > > I'm unsure if you have compiled something or are using the command line > tool. > >  There are lots of very

Re: [sqlite] column output truncating

Could you include a bit more information about your post? (Version number, operating system etc.) I'm unsure if you have compiled something or are using the command line tool. There are lots of very knowledgeable and helpful people on the list. On Thu, Apr 22, 2010 at 6:31 PM, Derek Martin

Re: [sqlite] Direct access of table data

I am using the Begin and Commit. On 4/23/2010 9:04 AM, Black, Michael (IS) wrote: > > So try creating your additional index, use the BEGIN/COMMIT, and let > us know how it performs for you in comparison. I'll bet its faster > even with the new index. > > You didn't say if you were already

Re: [sqlite] Is there any memory leak in the code while being busy?

You need to sqlite3_free(sql) after you use the sql from your sqlite3_mprintf(). sql = sqlite3_mprintf (sql_f, i); ret = sqlite3_prepare_v2 (db1, sql, -1, _stmt, NULL); sqlite3_free(sql); Michael D. Black Senior Scientist Northrop Grumman Mission Systems

Re: [sqlite] Direct access of table data

How long would it take to test using an index with 18 fields? Might not be crazy. Gerry On 4/23/10, Nathan Biggs wrote: > Max, thanks for the information. That will be very useful for other > table queries, but not for this one. For my table in questions there > are 18

Re: [sqlite] Direct access of table data

So try creating your additional index, use the BEGIN/COMMIT, and let us know how it performs for you in comparison. I'll bet its faster even with the new index. You didn't say if you were already doing the BEGIN/COMMIT. Michael D. Black Senior Scientist Northrop Grumman Mission Systems

Re: [sqlite] Direct access of table data

Yes, I do use batch inserts. On 4/23/2010 8:56 AM, Black, Michael (IS) wrote: > > If insert speed is important are you doing batch inserts? > If so, you want to do a BEGIN/COMMIT to speed up your inserts a LOT. > Default action is to defer which mean no database locks occur during > your

Re: [sqlite] Direct access of table data

If insert speed is important are you doing batch inserts? If so, you want to do a BEGIN/COMMIT to speed up your inserts a LOT. Default action is to defer which mean no database locks occur during your inserts. http://www.sqlite.org/lang_transaction.html Michael D. Black Senior Scientist

Re: [sqlite] Direct access of table data

Max, thanks for the information. That will be very useful for other table queries, but not for this one. For my table in questions there are 18 fields. I think an index with 18 fields would be a little crazy. On 4/23/2010 3:06 AM, Max Vlasov wrote: > > > ...As I add more restrictions on the

Re: [sqlite] Is there any memory leak in the code while being busy?

On 23 Apr 2010, at 1:16pm, liubin liu wrote: > But I test the routine of sqlite3_prepare_v2() + sqlite3_step() + > sqlite3_finalize() in my real code. > > And the test result say when sqlite3_step() is shadowed, the leak is zero. > When doing the sqlite3_step(), the leak is about 1k byte. And

Re: [sqlite] Is there any memory leak in the code while being busy?

sorry for multi-send the message. I just test the code again. And sqlite3_finalize() may free the memory. I'm wrong in the first post. But I test the routine of sqlite3_prepare_v2() + sqlite3_step() + sqlite3_finalize() in my real code. And the test result say when sqlite3_step() is shadowed,

Re: [sqlite] Is there any memory leak in the code ?

On Apr 23, 2010, at 2:34 PM, liubin liu wrote: > > Is there any memory leak in the code? The buffers returned by sqlite3_mprintf(). ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Is there any memory leak in the code while being busy?

it is not necessary to send your question multible times... ;) to answer: what makes you think that sqlite3_finalize can't free the prepared statement ? liubin liu wrote: > Is there any memory leak in the code? > > Below is the code. Is there any memory leak in the pthread2? > > While

[sqlite] Is there any memory leak in the code while being busy?

Is there any memory leak in the code? Below is the code. Is there any memory leak in the pthread2? While pthread1 is using test.db exclusively, the sqlite3_prepare_v2() of pthread2 still prepares the p_stmt pointer to a piece of memory malloced by sqlite3_preapare_v2(). And then the

[sqlite] Is there any memory leak in the code ?

Is there any memory leak in the code? Below is the code. Is there any memory leak in the pthread2? While pthread1 is using test.db exclusively, the sqlite3_prepare_v2() of pthread2 still prepares the p_stmt pointer to a piece of memory malloced by sqlite3_preapare_v2(). And then the

Re: [sqlite] Direct access of table data

> ...As I add more restrictions on the where-clause it > tends to slow down. I realize that this is due to my indexes, but can't > add a lot of indexes because it slows down the insert speed which is > more important than the query speed. > Nathan, maybe you already knew but just in case... if

[sqlite] Is there any memory leak in the code?

Below is my code. My question is: Is there any memory leak in the pthread2? While pthread1 is using test.db exclusively, the sqlite3_prepare_v2() of pthread2 still prepares the p_stmt pointer to a piece of memory malloced by sqlite3_preapare_v2(). And then the sqlite3_finalize() can't free the