Re: [sqlite] sqlite3_progress_handler(D,N,X,P)

? From: sqlite-users on behalf of R Smith Sent: Thursday, May 24, 2018 5:03:14 PM To: sqlite-users@mailinglists.sqlite.org Subject: Re: [sqlite] sqlite3_progress_handler(D,N,X,P) On 2018/05/24 5:41 PM, x wrote: > The parameter N is the approximate number of virt

Re: [sqlite] sqlite3_progress_handler(D,N,X,P)

On 2018/05/24 5:41 PM, x wrote: The parameter N is the approximate number of virtual machine instructions that are evaluated between successive invocations of the callback X. Would it not have been better if N was the number of milliseconds between invocations

[sqlite] sqlite3_progress_handler(D,N,X,P)

The parameter N is the approximate number of virtual machine instructions that are evaluated between successive invocations of the callback X. Would it not have been better if N was the number of milliseconds between invocations? It’s not much use if you want to

[sqlite] sqlite3_progress_handler do not seem to be called byvacuum

Hello ! Also a related question, if a database already has stats tables do we need to run analize after a vacuum ? Or vacuum is smart enough to see the stats tables and run analize by itself ? Cheers ! > Thu Mar 17 2016 08:51:11 PM CET from "Richard Hipp" >Subj

[sqlite] sqlite3_progress_handler do not seem to be called byvacuum

heers ! > Thu Mar 17 2016 08:51:11 PM CET from "Richard Hipp" >Subject: Re: [sqlite] sqlite3_progress_handler do not seem to be called >byvacuum > > On 3/17/16, Domingo Alvarez Duarte wrote: > >>Hello ! >> >> Hello I have an application th

[sqlite] sqlite3_progress_handler do not seem to be called by vacuum

Hello ! Hello I have an application that uses sqlite3_progress_handler to update a gui application and when we do a "vacuum" on a big database the gui get frozen, maybe vacuum should use different parameters to call sqlite3_progress_handler I'm using actually: db.progress_handler(1000, sqlite

[sqlite] sqlite3_progress_handler do not seem to be called by vacuum

On 17 Mar 2016, at 7:34pm, Domingo Alvarez Duarte wrote: > Hello I have an application that uses sqlite3_progress_handler to update a > gui application and when we do a "vacuum" on a big database the gui get > frozen VACUUM gets translated into just one virtual machine instruction. Since it's

[sqlite] sqlite3_progress_handler do not seem to be called byvacuum

On 3/17/16, Domingo Alvarez Duarte wrote: > Hello ! > > Also a related question, if a database already has stats tables do we need > to > run analize after a vacuum ? Or vacuum is smart enough to see the stats > tables and run analize by itself ? VACUUM does not change the stats, so it does not m

[sqlite] sqlite3_progress_handler do not seem to be called by vacuum

On 3/17/16, Domingo Alvarez Duarte wrote: > Hello ! > > Hello I have an application that uses sqlite3_progress_handler to update a > gui application and when we do a "vacuum" on a big database the gui get > frozen, maybe vacuum should use different parameters to call > sqlite3_progress_handler I'm

Re: [sqlite] sqlite3_progress_handler callback behavior change

Hi, > On 13 Mar 2014, at 13:21, big stone wrote: > Does it mean we may have SQLite3.8.4.1 in imminent Python 3.4 release ? > > http://bugs.python.org/issue20901 This question did come up when building/packaging that and other versions of Python with SQLite 3.8.4(.1), where that caused a test f

Re: [sqlite] sqlite3_progress_handler callback behavior change

Hello Andreas, Does it mean we may have SQLite3.8.4.1 in imminent Python 3.4 release ? http://bugs.python.org/issue20901 ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] sqlite3_progress_handler callback behavior change

On Wed, Mar 12, 2014 at 5:27 PM, Andreas Stieger wrote: > Hello, > > I noticed a change in behavior of sqlite3_progress_handler for CREATE > TABLE, or rather the calls to the callbacks, and just wanted to get > clarification if this was intentional. > > Specifically, given the code below for a cal

[sqlite] sqlite3_progress_handler callback behavior change

Hello, I noticed a change in behavior of sqlite3_progress_handler for CREATE TABLE, or rather the calls to the callbacks, and just wanted to get clarification if this was intentional. Specifically, given the code below for a callback that prints one "." for each code for this: (full code below) s

Re: [sqlite] Sqlite3_progress_handler and automatic rollback

On Thu, Oct 28, 2010 at 2:03 PM, Max Vlasov wrote: > > The problem is that (tested with 3.6.10 and 3.7.2) if : > - I interrupt a query from Sqlite3_progress_handler > - I didn't invoke this error-processing rollback, > > ...sqlite after that does the following: > - sqlite3_get_autocommit starts t

[sqlite] Sqlite3_progress_handler and automatic rollback

Hi, I try to use Sqlite3_progress_handler in my program and everything seems work fine, except for some unexplained things related to rollback and Sqlite3_get_autocommit function. I assume that everything that is related to sqlite3_interrupt can be applied to interrupting from Sqlite3_progress_han

[sqlite] sqlite3_progress_handler, sqlite3_commit_hook

@list Following the documentation, the two functions have been declared 'experimental'. Does someone know, how reliable these calls are actually ? There are specific serious open issues, rough estimates when to fix them, etc. ? Micha

Re: [sqlite] sqlite3_progress_handler

Marco Bambini <[EMAIL PROTECTED]> wrote: > From the documentation: "If the progress callback returns a result > other than 0, then the current query is immediately terminated...", > so next time I call sqlite3_step what is the error returned? > SQLITE_ERROR or SQLITE_ABORT or something else?

[sqlite] sqlite3_progress_handler

From the documentation: "If the progress callback returns a result other than 0, then the current query is immediately terminated...", so next time I call sqlite3_step what is the error returned? SQLITE_ERROR or SQLITE_ABORT or something else? Thanks a lot. --- Marco Bambini http://www.sqla