Re: [sqlite] SQLite4 release date and how to compile on windows platform
Thanks Gabriel. That answers my question. Thanks, Zarian. Sent from Yahoo! Mail on Android ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Inserting or replacing in the same db based on one key
On Wed, 9 Oct 2013 17:00:36 -0400 "jose isaias cabrera" wrote: > CREATE TABLE SimplePrices ( > cust TEXT, > class TEXT, > slang TEXT, > tlang TEXT, > TransferCost, > Price, > PRIMARY KEY (cust, class, slang, tlang)); > > and I have lots of data data. What I would like to do is to be able > to copy records to the same table. So, imagine that you have a set > of records where cust='XEROX' and you would like to copy all of those > records to a new cust say, 'XEROX1'. INSERT INTO SimplePrices SELECT cust || '1', class, slang, tlang, TransferCost, Price FROM SimplePrices WHERE cust = 'XEROX'; Kudos for the primary key declaration, btw. :-) --jkl ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Inserting or replacing in the same db based on one key
Greetings. I have this table creation code, CREATE TABLE SimplePrices ( cust TEXT, class TEXT, slang TEXT, tlang TEXT, TransferCost, Price, PRIMARY KEY (cust, class, slang, tlang)); and I have lots of data data. What I would like to do is to be able to copy records to the same table. So, imagine that you have a set of records where cust='XEROX' and you would like to copy all of those records to a new cust say, 'XEROX1'. I have been trying to figure this out using SQL comands, but don't seem to get the syntax or even one command. I can do it programmatically outside SQL, SELECT * from SimplePrices where cust = 'XEROX'; and then replace the cust field with 'XEROX1' and INSERT OR REPLACE, but I thought that I can ask and see if this is a possibility in one SQL command. Is this possible? thanks. josé ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug: analyze.c does not honor SQLITE_64BIT_STATS
On Wed, Oct 9, 2013 at 9:49 PM, James K. Lowden wrote: > > It's difficult to do portably because you have to account for every > combination of standard C library and integer size > Remember that SQLite does not use the standard library printf() function. It has its own. (See http://www.sqlite.org/src/artifact/da9119eb?ln=163) And the SQLite version assumes that %lld means 64-bit integer and %d means 32-bit integer. I think that http://www.sqlite.org/src/info/e97d7d3044 fixes this issue. Please correct me if I've missed something. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug: analyze.c does not honor SQLITE_64BIT_STATS
On Wed, 09 Oct 2013 10:20:13 -0400 Ryan Johnson wrote: > > This is more portable: > > > > #ifdef SQLITE_64BIT_STATS > > sqlite3_snprintf(24, zRet, "%lld", p->nRow); > > #else > > sqlite3_snprintf(24, zRet, "%d", p->nRow); > > #endif > Actually, some machines define 64-bit ints as long, (Compilers, that is, not machines.) > Technically the portable way is to make sure the int is a [u]int64_t > from and then use the (awful and painful) printf > modifiers from the same header (PRIu64 et al). An easier workaround > is to define the int as size_t and then use %zd in printf... but I > think % zd is a GNU extension. The applicable section of the C11 standard is 7.19.6.1. The PRI-style modifiers do not appear in it. The z modifer does. Last I checked, though, Microsoft's implementation didn't support it. It's difficult to do portably because you have to account for every combination of standard C library and integer size, and the grammar supported by the printf implementation cannot be determined systematically at compile-time or runtime. Even testing for compiler vendor and version is an inference because, technically, it says nothing about which runtime library is being linked to. --jkl ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] COMMIT in SQLite
Thanks guys. Perhaps docs could be updated in the _prepare_v2 section, to mention the 'best practices' lifecycle of a statement in regards to commit On 9 October 2013 04:08, Stephan Beal wrote: > On Tue, Oct 8, 2013 at 9:58 PM, Petite Abeille >wrote: > > > > > On Oct 8, 2013, at 8:10 PM, Stephan Beal wrote: > > > > > (link to the original post not included because the archives are only > > > visible to list members): > > > > Hmm? > > > > http://news.gmane.org/gmane.comp.version-control.fossil-scm.user > > > Sorry for the confusion: that was on fossil-dev, which isn't publicly > archived. > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/fossil-dev > > -- > - stephan beal > http://wanderinghorse.net/home/stephan/ > http://gplus.to/sgbeal > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] getting more context on SQL parse errors
I second that. Staffan On Tue, Oct 8, 2013 at 7:25 PM, Nelson, Erik - 2 < erik.l.nel...@bankofamerica.com> wrote: > When a SQL parsing error happens, the message returned by sqlite3_errmsg() > is pretty terse... is there some way to retrieve more context, so that the > user has more than one token to help locate the problem? > > For example, having the previous several tokens that were successfully > parsed would give a better idea of where to look for the SQL error. > > Thanks > > Erik > > -- > This message, and any attachments, is for the intended recipient(s) only, > may contain information that is privileged, confidential and/or proprietary > and subject to important terms and conditions available at > http://www.bankofamerica.com/emaildisclaimer. If you are not the > intended recipient, please delete this message. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Easy way to change a column
On Oct 9, 2013, at 2:50 AM, Bao Niu wrote: > For SQLite is there an easy way to find out ALL other tables, queries and > triggers that will be affected when performing a change to a particular > column under the cursor? No. > That would make refactoring so much easier. Yes. Let us know if you come up with something clever. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug: analyze.c does not honor SQLITE_64BIT_STATS
On 09/10/2013 10:07 AM, Ralf Junker wrote: On 09.10.2013 15:50, Eric Minbiole wrote: With this change, tests pass again: #if sizeof(p->nRow) == sizeof(long long) sqlite3_snprintf(24, zRet, "%lld", p->nRow); #elseif sizeof(p->Row) = sizeof(long) sqlite3_snprintf(24, zRet, "%ld", p->nRow); #else sqlite3_snprintf(24, zRet, "%d", p->nRow); #endif Slightly off-topic, but I didn't think that sizeof() could be used as part of a preprocessor directive? (I.e., that #if sizeof(x) doesn't work as intended, or at least not portably.) This is more portable: #ifdef SQLITE_64BIT_STATS sqlite3_snprintf(24, zRet, "%lld", p->nRow); #else sqlite3_snprintf(24, zRet, "%d", p->nRow); #endif Actually, some machines define 64-bit ints as long, and passing them to printf with %lld triggers compiler warnings [1]. Technically the portable way is to make sure the int is a [u]int64_t from and then use the (awful and painful) printf modifiers from the same header (PRIu64 et al). An easier workaround is to define the int as size_t and then use %zd in printf... but I think %zd is a GNU extension. [1] in that particular case the warning is harmless, but it's a bad idea to train oneself to ignore printf warnings about variable sizes, lest problems like the one we're discussing arise. Ryan ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug: analyze.c does not honor SQLITE_64BIT_STATS
On 09.10.2013 15:50, Eric Minbiole wrote: With this change, tests pass again: #if sizeof(p->nRow) == sizeof(long long) sqlite3_snprintf(24, zRet, "%lld", p->nRow); #elseif sizeof(p->Row) = sizeof(long) sqlite3_snprintf(24, zRet, "%ld", p->nRow); #else sqlite3_snprintf(24, zRet, "%d", p->nRow); #endif Slightly off-topic, but I didn't think that sizeof() could be used as part of a preprocessor directive? (I.e., that #if sizeof(x) doesn't work as intended, or at least not portably.) This is more portable: #ifdef SQLITE_64BIT_STATS sqlite3_snprintf(24, zRet, "%lld", p->nRow); #else sqlite3_snprintf(24, zRet, "%d", p->nRow); #endif Ralf ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug: analyze.c does not honor SQLITE_64BIT_STATS
On 10/9/2013 9:50 AM, Eric Minbiole wrote: With this change, tests pass again: #if sizeof(p->nRow) == sizeof(long long) sqlite3_snprintf(24, zRet, "%lld", p->nRow); #elseif sizeof(p->Row) = sizeof(long) sqlite3_snprintf(24, zRet, "%ld", p->nRow); #else sqlite3_snprintf(24, zRet, "%d", p->nRow); #endif Slightly off-topic, but I didn't think that sizeof() could be used as part of a preprocessor directive? (I.e., that #if sizeof(x) doesn't work as intended, or at least not portably.) #elseif also looks like a compiler-specific non-portable extension. The correct spelling is #elif -- Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Bug: analyze.c does not honor SQLITE_64BIT_STATS
> With this change, tests pass again: > > #if sizeof(p->nRow) == sizeof(long long) > sqlite3_snprintf(24, zRet, "%lld", p->nRow); > #elseif sizeof(p->Row) = sizeof(long) > sqlite3_snprintf(24, zRet, "%ld", p->nRow); > #else > sqlite3_snprintf(24, zRet, "%d", p->nRow); > #endif > > Slightly off-topic, but I didn't think that sizeof() could be used as part of a preprocessor directive? (I.e., that #if sizeof(x) doesn't work as intended, or at least not portably.) ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Bug: analyze.c does not honor SQLITE_64BIT_STATS
analyze.c always prints 32-bit variables as 64-bit here: http://www.sqlite.org/src/artifact/d322972af09e3f8debb45f420dfe3ded142b108b?ln=746 http://www.sqlite.org/src/artifact/d322972af09e3f8debb45f420dfe3ded142b108b?ln=792 This can cause wrong sqlite_statX tables which I have experienced compiling for 32-bit. With this change, tests pass again: #if sizeof(p->nRow) == sizeof(long long) sqlite3_snprintf(24, zRet, "%lld", p->nRow); #elseif sizeof(p->Row) = sizeof(long) sqlite3_snprintf(24, zRet, "%ld", p->nRow); #else sqlite3_snprintf(24, zRet, "%d", p->nRow); #endif Ralf ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
