[sqlite] How to see SQLite debugging information
> You did you manage to implement new UDFs if you are not a C programmer? I forgot to say that the actual callback functions (the actual code that performs the manipulations) is not in SQLite, but in that ActiveX dll. RBS On Tue, Dec 8, 2015 at 10:09 PM, Richard Hipp wrote: > On 12/8/15, Bart Smissaert wrote: > > Having a problem where 2 UDF's in one SQL cause a crash in my application > > (Excel) > > originating from SQLite. This is on Windows 7 with the latest SQLite > > version. > > I have a sqlite3.dll compiled with these compiler options: > > > > -DSQLITE_DEBUG > > -DSQLITE_MEMDEBUG > > -DSQLITE_OMIT_LOOKASIDE > > > > I can run PRAGMA vdbe_debug = 1 > > > > But how do I see now any useful debugging information that could make me > > understand > > this crash? I am not a C programmer. Is there an option somewhere to > dump a > > log file? > > The "PRAGMA vdbe_debug=ON;" command should give you copious amounts of > debugging information on standard output. Does it not? > > You did you manage to implement new UDFs if you are not a C programmer? > > -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] How to see SQLite debugging information
> on standard output But how this work in concrete steps? Does code have to be added to SQLite to write for example to a text file? The Explain command doesn't produce this information or can it? > You did you manage to implement new UDFs if you are not a C programmer? Somebody familiar with C added this to a std_call dll and I picked it up from that via a .tlb file and an ActiveX (VB6) dll. All working fine, except in that mentioned situation. RBS On Tue, Dec 8, 2015 at 10:09 PM, Richard Hipp wrote: > On 12/8/15, Bart Smissaert wrote: > > Having a problem where 2 UDF's in one SQL cause a crash in my application > > (Excel) > > originating from SQLite. This is on Windows 7 with the latest SQLite > > version. > > I have a sqlite3.dll compiled with these compiler options: > > > > -DSQLITE_DEBUG > > -DSQLITE_MEMDEBUG > > -DSQLITE_OMIT_LOOKASIDE > > > > I can run PRAGMA vdbe_debug = 1 > > > > But how do I see now any useful debugging information that could make me > > understand > > this crash? I am not a C programmer. Is there an option somewhere to > dump a > > log file? > > The "PRAGMA vdbe_debug=ON;" command should give you copious amounts of > debugging information on standard output. Does it not? > > You did you manage to implement new UDFs if you are not a C programmer? > > -- > D. Richard Hipp > drh at sqlite.org > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
[sqlite] How to see SQLite debugging information
On 12/8/15, Bart Smissaert wrote: > So, what/where is that standard output channel? > This is on a Win7 machine. How do I bring up that console window? > The standard output is what displays on your screen when you are in a DOS box. SQLite does not have any facilities for debugging in a GUI on Windows. -- D. Richard Hipp drh at sqlite.org
[sqlite] How to see SQLite debugging information
Having a problem where 2 UDF's in one SQL cause a crash in my application (Excel) originating from SQLite. This is on Windows 7 with the latest SQLite version. I have a sqlite3.dll compiled with these compiler options: -DSQLITE_DEBUG -DSQLITE_MEMDEBUG -DSQLITE_OMIT_LOOKASIDE I can run PRAGMA vdbe_debug = 1 But how do I see now any useful debugging information that could make me understand this crash? I am not a C programmer. Is there an option somewhere to dump a log file? RBS
[sqlite] How to see SQLite debugging information
On Tue, Dec 8, 2015 at 4:30 PM, Bart Smissaert
wrote:
> So, what/where is that standard output channel?
> This is on a Win7 machine. How do I bring up that console window?
> There is no development environment here. I am running this from Excel.
> So, I have a standard Windows sqlite3.dll, a std_call dll (to make SQLite
> accessible to VB6)
Are you using Excel or VB6? They're very different things.
You could try adding something like the following to somewhere near
the beginning of sqlite3_initialize
freopen("sqlite_stdout.txt","a",stdout);
freopen("sqlite_stderr.txt","a",stderr);
This will create two text files for all of sqlite's output. There
might be side effects to doing this .. honestly I have no idea if
it'll work, and finding where the files are created might be
interesting (they'll be the current directory, but I have no idea what
that is when you're running Excel, or VB6)
Really, this problem is best solved with a debugger. Even windbg is
better than flying blind, and you can step through the sqlite code in
a debug build even if it's being loaded by something like Excel where
you don't have the source code.
[sqlite] How to see SQLite debugging information
On 12/8/15, Bart Smissaert wrote: > Having a problem where 2 UDF's in one SQL cause a crash in my application > (Excel) > originating from SQLite. This is on Windows 7 with the latest SQLite > version. > I have a sqlite3.dll compiled with these compiler options: > > -DSQLITE_DEBUG > -DSQLITE_MEMDEBUG > -DSQLITE_OMIT_LOOKASIDE > > I can run PRAGMA vdbe_debug = 1 > > But how do I see now any useful debugging information that could make me > understand > this crash? I am not a C programmer. Is there an option somewhere to dump a > log file? The "PRAGMA vdbe_debug=ON;" command should give you copious amounts of debugging information on standard output. Does it not? You did you manage to implement new UDFs if you are not a C programmer? -- D. Richard Hipp drh at sqlite.org
[sqlite] NOP INSERT still writes to the DB/journal
On 2015/12/08 12:16 PM, Domingo Alvarez Duarte wrote: > If I understood correctly when no transaction is specified an implicit > transaction is created so there is no point to create a transaction for only > one statement. Yes, but what Simon is trying to achieve is to have the transaction explicitly record to the journal so as to avoid locking the tables until the transaction concludes, which we are hoping would allow the Query engine time to realize that there needn't be a table write at all (since zero records were selected), and so commit the journal without actually locking the table. Makes sense? > Try this ... > > BEGIN > INSERT INTO t1 ... > END > > See whether the INSERT command still involves as much writing. > > Simon. >
[sqlite] NOP INSERT still writes to the DB/journal
On 8 Dec 2015, at 10:16am, Domingo Alvarez Duarte wrote: > If I understood correctly when no transaction is specified an implicit > transaction is created so there is no point to create a transaction for only > one statement. The OP here has lots of INSERT commands and is complaining that they do reading and writing even when they have no effect. My point was that it was the implicit transaction commands (BEGIN and END) which were doing the writing. And this means that every INSERT command does some writing even when no rows are actually inserted. If the OP does a BEGIN first, he should be able do many of his INSERT commands and they will not do any writing. However I have not tested this with the trace routines and it may not turn out to be true. Simon.
[sqlite] NOP INSERT still writes to the DB/journal
If I understood correctly when no transaction is specified an implicit transaction is created so there is no point to create a transaction for only one statement. Cheers ! > Tue Dec 08 2015 5:51:35 am CET CET from "Simon Slavin" > Subject: Re: [sqlite] NOP INSERT still writes to the >DB/journal > > On 8 Dec 2015, at 12:19am, Patrick Donnelly wrote: > > >>There are still writes: >> > Because you have not defined any transactions, each of your INSERT >commands it getting wrapped in its own transaction. A transaction has to >involve writes to disk. > > Try this ... > > BEGIN > INSERT INTO t1 ... > END > > See whether the INSERT command still involves as much writing. > > Simon. > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > ?
[sqlite] NOP INSERT still writes to the DB/journal
On Mon, Dec 7, 2015 at 11:51 PM, Simon Slavin wrote:
>
> On 8 Dec 2015, at 12:19am, Patrick Donnelly wrote:
>
>> There are still writes:
>
> Because you have not defined any transactions, each of your INSERT commands
> it getting wrapped in its own transaction. A transaction has to involve
> writes to disk.
>
> Try this ...
>
> BEGIN
> INSERT INTO t1 ...
> END
>
> See whether the INSERT command still involves as much writing.
This problem is not related to transactions. Richard Hipp posted an
example [1] where there are no writes for an "INSERT INTO T SELECT..."
on a table (without AUTOINCREMENT), without any explicit
transactions.
My own test example without AUTOINCREMENT has no writes:
$ cat test2.sql
CREATE TABLE t1(a INTEGER PRIMARY KEY, b integer);
INSERT INTO t1(b) VALUES (1);
.print -
begin transaction;
INSERT INTO t1 (b)
SELECT 0
WHERE 1 = 0;
end transaction;
select changes();
$ diff test.sql test2.sql
1c1
< CREATE TABLE t1(a INTEGER PRIMARY KEY AUTOINCREMENT, b integer);
---
> CREATE TABLE t1(a INTEGER PRIMARY KEY, b integer);
3d2
< select * from sqlite_sequence;
$ rm foo.db*; ./sqlite3 -vfstrace foo.db < test2.sql
...
-
trace.xLock(foo.db,SHARED) -> SQLITE_OK
trace.xAccess("/home/batrick/sqlite-amalgamation-3090200/foo.db-journal",0)
-> SQLITE_OK, out=0
trace.xFileSize(foo.db) -> SQLITE_OK, size=2048
trace.xRead(foo.db,n=16,ofst=24) -> SQLITE_OK
trace.xFileSize(foo.db) -> SQLITE_OK, size=2048
trace.xAccess("/home/batrick/sqlite-amalgamation-3090200/foo.db-wal",0)
-> SQLITE_OK, out=0
trace.xFileSize(foo.db) -> SQLITE_OK, size=2048
trace.xLock(foo.db,RESERVED) -> SQLITE_OK
trace.xLock(foo.db,EXCLUSIVE) -> SQLITE_OK
trace.xFileControl(foo.db,22) -> 12
trace.xUnlock(foo.db,SHARED) -> SQLITE_OK
trace.xDeviceCharacteristics(foo.db) -> 0x1000
trace.xUnlock(foo.db,NONE) -> SQLITE_OK
0
trace.xDeviceCharacteristics(foo.db) -> 0x1000
trace.xUnlock(foo.db,NONE) -> SQLITE_OK
trace.xClose(foo.db) -> SQLITE_OK
[1]
http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2014-May/052855.html
--
Patrick Donnelly
[sqlite] NOP INSERT still writes to the DB/journal
If you execute an SQL statement in automagic mode, then BEGIN and COMMIT are magically wrapped around the statement -- you are absolutely correct and that is the purpose of the magic mode. Therefore doing: BEGIN; INSERT ... COMMIT; is EXACTLY IDENTICAL to INSERT with full automagic engaged. The only difference ... tada ... is that you get to see the processing associated with performing the magic, which was previously obscured from your view (or rather, was plainly obvious but you could not distinguish the processing caused by the magic and the processing caused by your INSERT ... statement). I believe Simon's point is that if you use "Manual Magic" then you can see the processing associated with that magic, compared to full on automagic, where the actions contain such an intermix of magically initiated operations and explicitly initiation operations that a primitive observer is unable to tell which part is caused by the magic and which part is not. As Captain Pickard would point out, it explains the magic to a primitive culture that has never seen a door before. > -Original Message- > From: sqlite-users-bounces at mailinglists.sqlite.org [mailto:sqlite-users- > bounces at mailinglists.sqlite.org] On Behalf Of Domingo Alvarez Duarte > Sent: Tuesday, 8 December, 2015 03:17 > To: SQLite mailing list > Subject: Re: [sqlite] NOP INSERT still writes to the DB/journal > > If I understood correctly when no transaction is specified an implicit > transaction is created so there is no point to create a transaction for > only > one statement. > > Cheers ! > > Tue Dec 08 2015 5:51:35 am CET CET from "Simon Slavin" > > Subject: Re: [sqlite] NOP INSERT still writes to > the > >DB/journal > > > > On 8 Dec 2015, at 12:19am, Patrick Donnelly > wrote: > > > > > >>There are still writes: > >> > > > Because you have not defined any transactions, each of your INSERT > >commands it getting wrapped in its own transaction. A transaction has to > >involve writes to disk. > > > > Try this ... > > > > BEGIN > > INSERT INTO t1 ... > > END > > > > See whether the INSERT command still involves as much writing. > > > > Simon. > > ___ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > > > > > > > > > ___ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] NOP INSERT still writes to the DB/journal
On 8 Dec 2015, at 12:19am, Patrick Donnelly wrote: > There are still writes: Because you have not defined any transactions, each of your INSERT commands it getting wrapped in its own transaction. A transaction has to involve writes to disk. Try this ... BEGIN INSERT INTO t1 ... END See whether the INSERT command still involves as much writing. Simon.
[sqlite] sqlite3_errmsg and wide char
On 8 Dec 2015, at 12:31am, Scott Robison wrote: > This may be true of OS X, but it not true of Mac all through history. They > might not have been called "code pages" but Mac most definitely had > different character sets to support different markets. Yep. OS 9 supported string processing and printing in different character sets. OS X, released in the year 2000 was Unicode from the base up. There are API routines to translate to and from different code pages, but you can't do string processing or display with an octet stream, only ASCII and Unicode. Simon.
