Re: [sqlite] Application is crashing while performing sqlite3_prepare_v2 with sqlite version 3.15.2 (intermittently)

Hi Roshak, Looks like your top function in that thread is sqlite3_prepare_v2 So I can assume 2 things: 1 - you started a thread directly on sqlite3_prepare_v2 2- you erase part of the stack trace. if you did 1, I can only say this is not good! if you did 2, then you are keeping information,

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

PICCORO McKAY Lenz wrote: > an important feature in a DB its the column field that gives to developers > metadata info INDEPENDENT of the tecnologies used, due by this way with a > simple text editor in generated script developer can read and use minimal > info for understanding structure ...

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 2017/03/14 2:54 PM, PICCORO McKAY Lenz wrote: an important feature in a DB its the column field that gives to developers metadata info INDEPENDENT of the tecnologies used, due by this way with a simple text editor in generated script developer can read and use minimal info for understanding

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

I usually add a table with comments to other tables and fields for this. That does the trick for me. Is there another way to do it? 2017-03-14 13:54 GMT+01:00 PICCORO McKAY Lenz : > an important feature in a DB its the column field that gives to developers > metadata info

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Just add a 'comments' table. Seems a lot of extra work and 'extra tools' needed to read the comments, which could potentially be missed. Add a 'comments' table with a 'comment' field which you can even add dates, usernames, etc, to. Thanks, Chris On Wed, Mar 15, 2017 at 11:12 AM, Clemens

[sqlite] bounded id

Hello, I have a wire-protocol which uses an uint32_t to identify transfers, and each of the transfers is represented by a row in a table in an sqlite database. I can't make the rowid a uint32_t, but that's essentially the behavior I'm looking for -- I'd like to be able to insert a new row

[sqlite] Application is crashing while performing sqlite3_prepare_v2 with sqlite version 3.15.2 (intermittently)

Hi All, I am using sqlite as library in multi-threaded environment where multiple applications use sqlite queries to perform get/set operations on attributes available in sqlite db tables. Intermittently i am seeing applications crashing when get operation is performed which intern call

[sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

an important feature in a DB its the column field that gives to developers metadata info INDEPENDENT of the tecnologies used, due by this way with a simple text editor in generated script developer can read and use minimal info for understanding structure ... its a minimal feature need in a

Re: [sqlite] bounded id

Jan Danielsson wrote: > I can't make the rowid a uint32_t, but that's essentially the > behavior I'm looking for CREATE TABLE transfers ( ID INTEGER PRIMARY KEY CHECK (ID BETWEEN 0 AND 4294967295), [...] ); But if you want the values to wrap around after old ones have been deleted, you

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 15 Mar 2017, at 1:27pm, Brian Curley wrote: > The sqlite_master table will always preserve any comments embedded between > the "CREATE" and ";" keywords for a given table definition. Is this not > sufficient? I always found that interesting. I would have thought that

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

The sqlite_master table will always preserve any comments embedded between the "CREATE" and ";" keywords for a given table definition. Is this not sufficient? You can parse the sql for a table's record to retrieve comments, in whichever format you're using. I know that SQLite supports both single

Re: [sqlite] last_insert_rowid and FTS in 3.17

Head of trunk certainly fixes it ... SQLite version 3.18.0 2017-03-15 19:11:29 Enter ".help" for usage hints. Connected to a transient in-memory database. Use ".open FILENAME" to reopen on a persistent database. sqlite> select sqlite_source_id(); 2017-03-15 19:11:29

[sqlite] Maybe a bug

Running "testfixture.exe veryquick.test --verbose=file --output=test-out.txt" compiled with ICU support gives : Time: fts3ao.test 320 ms fts3atoken-3.3... Error: error in xOpen() .\testfixture.exe: error in xOpen() while executing "ifcapable icu { proc do_icu_test {name locale

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Can't you add it to the field name? For example for a field holding date of birth: DOB_INT or DOB_TXT. RBS On Tue, Mar 14, 2017 at 12:54 PM, PICCORO McKAY Lenz wrote: > an important feature in a DB its the column field that gives to developers > metadata info

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 15 Mar 2017, at 2:30pm, PICCORO McKAY Lenz wrote: > so can introduce a feature that converts all parts that have COMMENT '(\*)' > to /* COMMENT */ and stored? in the master part of the Database? It is unlikely that this will happen in SQLite3. What Brian is telling

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 3/15/17, Bob Friesenhahn wrote: > On Wed, 15 Mar 2017, R Smith wrote: >> >> CREATE TABLE "test" ( >> "ID" INTEGER /* Here we add column comments */, >> "Name" TEXT /* Note the comma is AFTER the comment */, >> "EMail" TEXT COLLATE NOCASE /* Username (Unique

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

Maybe it is simpler (no parsing needed) to have an extra table with a unique column holding tablename_fieldname and a second column holding the comment for that field. RBS On 15 Mar 2017 10:35, "R Smith" wrote: > > On 2017/03/14 2:54 PM, PICCORO McKAY Lenz wrote: > >> an

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

hey their'e WIDELY USED keyword and practice in all mayor DBMS so can introduce a feature that converts all parts that have COMMENT '(\*)' to /* COMMENT */ and stored? in the master part of the Database? and NOTED THAT no many users comes here due the complicated behavior of report an issue...

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

the idea its that many tools generated (due portability and compability) sql script with a optional keyword COMMENT on each column definition.. this its xxtremely usefull for selft container documentation for many console users and rapid development so manual comment using C-like cannot do that,

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 2017/03/15 5:36 PM, Richard Hipp wrote: On 3/15/17, Bob Friesenhahn wrote: On Wed, 15 Mar 2017, R Smith wrote: CREATE TABLE "test" ( "ID" INTEGER /* Here we add column comments */, "Name" TEXT /* Note the comma is AFTER the comment */, "EMail" TEXT

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On Wed, 15 Mar 2017, R Smith wrote: What we do (typically), since SQLite supports C-type comment blocks /* ... */, is to add comment lines to the schema and they are preserved correctly. For example: CREATE TABLE "test" ( "ID" INTEGER /* Here we add column comments */, "Name" TEXT /* Note

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 2017/03/15 5:15 PM, PICCORO McKAY Lenz wrote: so manual comment using C-like cannot do that, if i have a large set of DB's with minimal of 20 tables, its widelly tedious manage comments in that way that some here sugest me.. and later joint the db files for work? Well, the advantage of

Re: [sqlite] last_insert_rowid and FTS in 3.17

On 3/15/17, Hugo Beauzée-Luyssen wrote: > Hi, I'm having some issues with last_insert_rowid starting with 3.17 > Basically it seems to be returning the row inserted by a trigger, > instead of the explicitly inserted row. Please try the latest pre-release snapshot at

[sqlite] last_insert_rowid and FTS in 3.17

Hi, Hi, I'm having some issues with last_insert_rowid starting with 3.17 Basically it seems to be returning the row inserted by a trigger, instead of the explicitly inserted row. As far as I understand, this contradicts the last_insert_rowid() documentation. I wrote a small test case to

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On Wed, Mar 15, 2017 at 4:57 PM, R Smith wrote: > I wonder, sqlite Devs, if a pragma or other adaption (such as the current > pragma table_info()) or such could produce the same exact data but with an > added field called "Comment" that simply gives the parsed comment from >

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

2017-03-15 12:24 GMT-04:00 Simon Slavin : > Problem is, it requires parsing the CREATE command looking for comments in > a certain format. Notoriously difficult, considering that they can contain > CR, LF, tab, and unforeseen Unicode characters. > well limit the comment to

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 15 Mar 2017, at 4:09pm, Dominique Devienne wrote: > On Wed, Mar 15, 2017 at 4:57 PM, R Smith wrote: > >> I wonder, sqlite Devs, if a pragma or other adaption (such as the current >> pragma table_info()) or such could produce the same exact data but

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

2017-03-15 11:49 GMT-04:00 R Smith : > Well, the advantage of having comments in DB tables (as some suggested) is > also that you have the entire SQL language functions available to > manipulate the comments that's one firts reason that rely on the second, comment can handle

Re: [sqlite] feature req: PLEASE why the heck COMMENT fields are not supporte in years!!

On 15 Mar 2017, at 2:45pm, Bart Smissaert wrote: > Maybe it is simpler (no parsing needed) to have an extra table with a > unique column holding tablename_fieldname > and a second column holding the comment for that field. It’s common to see a four column table, with

Re: [sqlite] A CTE to count the records (rows) for each table

> > Does anyone knows a Common Table Expression (CTE) to be used with the > > sqlite_master table so we can count for each table how many rows it > > has. I wonder if it's always accurate to piggyback on the work of ANALYZE and obtain row counts as of the last ANALYZE via: select tbl,

Re: [sqlite] A CTE to count the records (rows) for each table

On 3/15/17, Donald Griggs wrote: >> > Does anyone knows a Common Table Expression (CTE) to be used with the >> > sqlite_master table so we can count for each table how many rows it >> > has. > > I wonder if it's always accurate to piggyback on the work of ANALYZE and >

Re: [sqlite] FTS5 not working

On 03/15/2017 06:00 AM, Domingo Alvarez Duarte wrote: Hello ! I just downloaded the http://www.sqlite.org/snapshot/sqlite-snapshot-201703062044.tar.gz compiled it with fts5 enabled and then tested it with this: === CREATE VIRTUAL TABLE email USING fts5(body); insert into email(body)