Re: [sqlite] Tcl sqlite3 bindings - NULL handling in `$db eval $sql array { ... }`

On 6/26/17, 11:48 AM, "drhsql...@gmail.com on behalf of Richard Hipp" wrote: > OK. I'll back out the change, then. That’s definitely safer, it’s a super useful capability but needs to be applied selectively.

Re: [sqlite] Tcl sqlite3 bindings - NULL handling in `$db eval $sql array { ... }`

OK. I'll back out the change, then. On 6/26/17, Peter da Silva wrote: > This is really a pretty major change. > > Our experience with the comparable options in Pgtcl and Speedtables is that > there is likely a lot of code that assumes that all array elements are

Re: [sqlite] Tcl sqlite3 bindings - NULL handling in `$db eval $sql array { ... }`

On 6/26/17, Peter da Silva wrote: > On 6/26/17, 11:15 AM, "drhsql...@gmail.com on behalf of Richard Hipp" > wrote: >> If you get the latest check-in (https://www.sqlite.org/src/info/trunk) >> there is a new option

Re: [sqlite] Tcl sqlite3 bindings - NULL handling in `$db eval $sql array { ... }`

On 6/26/17, 11:15 AM, "drhsql...@gmail.com on behalf of Richard Hipp" wrote: > If you get the latest check-in (https://www.sqlite.org/src/info/trunk) there > is a new option on the "sqlite3" command called "-unsetnull 1" which causes > "db

Re: [sqlite] Tcl sqlite3 bindings - NULL handling in `$db eval $sql array { ... }`

If you get the latest check-in (https://www.sqlite.org/src/info/trunk) there is a new option on the "sqlite3" command called "-unsetnull 1" which causes "db eval" to work as you desire - by unsetting the array elements for NULL values. This option is off by default for legacy compatibility. On

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On Jun 26, 2017 9:02 AM, "Simon Slavin" wrote: There is no convention for "This software understands both UTF-16BE and UTF-16LE but nothing else.". If it handles any BOMs, it should handle all five. However, it can handle them by identifying, for example, UTF-32BE and

Re: [sqlite] UTF8-BOM not disregarded in CSV import

I didn’t mean to imply you had to scan the whole content for a BOM, but rather for illegal characters in the absence of a BOM. On 6/26/17, 10:02 AM, "sqlite-users on behalf of Simon Slavin" wrote: Folks, I’m

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On Jun 26, 2017 4:05 AM, "Rowan Worth" wrote: On 26 June 2017 at 16:55, Scott Robison wrote: > Byte Order Mark isn't perfectly descriptive when used with UTF-8. Neither > is dialing a cell phone. Language evolves. > It's not descriptive in the

Re: [sqlite] UTF8-BOM not disregarded in CSV import

Folks, I’m sorry to interrupt but I’ve just woken up to 11 posts in this thread and I see a lot of inaccurate 'facts' posted here. Rather than pick up on statements in individual posts (which would unfairly pick on some people as being less accurate than others) I’d like to post facts straight

Re: [sqlite] Could not load file or assembly error

> -Original Message- > From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On > Behalf Of Paul J. McMillan, Sr. > Sent: Thursday, June 22, 2017 1:51 PM > To: sqlite-users@mailinglists.sqlite.org > Subject: [sqlite] Could not load file or assembly error > > Hi, > > > >

Re: [sqlite] Document typo?

Should be fixed now. Thanks for the bug report. On 6/26/17, Paul Sanderson wrote: > https://sqlite.org/dbstat.html > > The DBStat web page defines that schema of the virtual table as follows > with path defined as an integer > > CREATE TABLE dbstat( > name

[sqlite] Document typo?

https://sqlite.org/dbstat.html The DBStat web page defines that schema of the virtual table as follows with path defined as an integer CREATE TABLE dbstat( name STRING, -- Name of table or index path INTEGER,-- Path to page from root pageno INTEGER,-- Page

Re: [sqlite] Tcl sqlite3 bindings - NULL handling in `$db eval $sql array { ... }`

On 6/26/17, 9:00 AM, "sqlite-users on behalf of Richard Hipp" wrote: > The "db nullvalue STRING" command lets you translate NULL values into the > string value of your choice. But there is not (currently) a way to

Re: [sqlite] Tcl sqlite3 bindings - NULL handling in `$db eval $sql array { ... }`

On 6/26/17, Peter da Silva wrote: > What’s the best way to handle NULLs out of band when walking the results of > a query: > > $sqlite_db eval “SELECT * FROM table ...” array { > ... > } > > In other Tcl database bindings it’s common to return arrays

[sqlite] Tcl sqlite3 bindings - NULL handling in `$db eval $sql array { ... }`

What’s the best way to handle NULLs out of band when walking the results of a query: $sqlite_db eval “SELECT * FROM table ...” array { ... } In other Tcl database bindings it’s common to return arrays containing possible null values with NULL values simply unset, so `[info exists]` can

Re: [sqlite] UTF8-BOM not disregarded in CSV import

Just occurred to me: another problem with the BOM is that some people who are *not* writing UTF-8 are cargo-culting the BOM in anyway. So you may have to scan the whole file to see if it’s really UTF-8 anyway. You’re better off just assuming UTF-8 everywhere, generating an error (and backing

Re: [sqlite] UTF8-BOM not disregarded in CSV import

At the bottom... -Original Message- From: Eric Grange Sent: Monday, June 26, 2017 3:09 AM To: SQLite mailing list Subject: Re: [sqlite] UTF8-BOM not disregarded in CSV import Alas, there is no end in sight to the pain for the Unicode decision to not make the BOM compulsory for UTF-8.

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On 6/26/17, 2:09 AM, "sqlite-users on behalf of Eric Grange" wrote: > Alas, there is no end in sight to the pain for the Unicode decision to not > make the BOM compulsory for UTF-8. It’s not actually providing any

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On 6/26/17 3:09 AM, Eric Grange wrote: Alas, there is no end in sight to the pain for the Unicode decision to not make the BOM compulsory for UTF-8. Making it optional or non-necessary basically made every single text file ambiguous, with non-trivial heuristics and implicit conventions required

Re: [sqlite] UTF8-BOM not disregarded in CSV import

>Easily solved by never including a superflous BOM in UTF-8 text And that easy option has worked beautifully for 20 years... not. Yes, BOM is a misnommer, yes it "wastes" 3 bytes, but in the real world "text files" have a variety of encodings. No BOM = you have to fire a whole suite of

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On 26 June 2017 at 16:55, Scott Robison wrote: > Byte Order Mark isn't perfectly descriptive when used with UTF-8. Neither > is dialing a cell phone. Language evolves. > It's not descriptive in the slightest because UTF-8's byte order is *specified by the encoding*.

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On Jun 25, 2017 1:16 PM, "Cezary H. Noweta" wrote: Certainly, there are no objections to extend an import's functionality in such a way that it ignores the initial 0xFEFF. However, an import should allow ZWNBSP as the first character, in its basic form, to be conforming to

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On Jun 26, 2017 1:47 AM, "Rowan Worth" wrote: On 26 June 2017 at 15:09, Eric Grange wrote: > Alas, there is no end in sight to the pain for the Unicode decision to not > make the BOM compulsory for UTF-8. > UTF-8 is byte oriented. The very concept of byte

Re: [sqlite] operator precedence

Thanks for the replies. I noticed a while back that when I compiled using the 64 bit compiler (I’m using c++ builder 10.1 which I think is clang) it gave warnings when || and && were mixed but not bracketed. Was worried I had missed something. From: Simon Slavin

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On 26 June 2017 at 15:09, Eric Grange wrote: > Alas, there is no end in sight to the pain for the Unicode decision to not > make the BOM compulsory for UTF-8. > UTF-8 is byte oriented. The very concept of byte order is nonsense in this context as there is no multi-byte

Re: [sqlite] UTF8-BOM not disregarded in CSV import

On Sun, Jun 25, 2017 at 12:16 PM, Cezary H. Noweta wrote: > Hello, > > > The standard says: ``Only UTF-16/32 (even not UTF-16/32LE/BE) encoding > forms can contain BOM''. Let's conform to this. > > I concur with that. Since UTF-8 is only bytes; what would a BOM even change?

Re: [sqlite] UTF8-BOM not disregarded in CSV import

Alas, there is no end in sight to the pain for the Unicode decision to not make the BOM compulsory for UTF-8. Making it optional or non-necessary basically made every single text file ambiguous, with non-trivial heuristics and implicit conventions required instead, resulting in character