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
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
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
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
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
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
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
>
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
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
>
> 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
> 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
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
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
13 matches
Mail list logo
