[sqlite] Issue: Inconsistency of sqlite3_dbstat_register declaration

[Roger Binns]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

There is a forward declaration of sqlite3_dbstat_register (currently
line 130871 in the 3.8.10.1 amalgamation):

  int sqlite3_dbstat_register(sqlite3*);

Later is the actual implementation (currently line 155838 in the
3.8.10.1 amalgamation):

  SQLITE_API int SQLITE_STDCALL sqlite3_dbstat_register(sqlite3 *db){

If SQLITE_API or SQLITE_STDCALL are set to anything then the
inconsistency can cause a compiler error.  In my case SQLITE_API is
defined as static.

Compilation then fails with gcc on Linux:

/space/apsw/sqlite3/sqlite3.c:155838:12: error: static declaration of
?sqlite3_dbstat_register? follows non-static declaration

Roger
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iEYEARECAAYFAlVPrCoACgkQmOOfHg372QQEuwCgkCmhV/1ceig99me3QduAw7WL
qxUAniB4ZEF6KN52A/kAV/HZxVJ1kL9G
=686t
-END PGP SIGNATURE-

[sqlite] Two Threads Share In-Memory Table

[Peter Aronson]

See https://www.sqlite.org/sharedcache.html and in particular, section 6 
at the bottom.

Peter

On 5/10/2015 10:42 AM, Joe Pasquariello wrote:
> Hello,
>
> One thread of our Windows application is an HTTP server reading data 
> from an SQLite database for display by web clients. Some tables are 
> updated infrequently (minutes), but one contains current status of 
> numerous machines, and it is written/read relatively frequently. Data 
> is written to the DB by a dedicated writer thread. The 
> frequently-written table is temporary  in the sense that it is 
> dropped/created at run-time, and the data doesn't need to persist 
> between executions.
>
> My question is whether there is a way for this table to be in memory. 
> Each thread has its own connection, which I understand to be 
> necessary. Am I correct that this means they can't share an in-memory 
> DB or an in-memory TEMP table, because those are restricted to a 
> single connection? It's very convenient to use SQLite for this purpose 
> because each client may be interested in a different row or set of 
> rows from the "real-time" table, and it seems a shame for the shared 
> data to have to be on disk and not simply in memory.
>
> Thanks,
>
> Joe
> ___
> sqlite-users mailing list
> sqlite-users at mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>

[sqlite] Two Threads Share In-Memory Table

[Joe Pasquariello]

Hello,

One thread of our Windows application is an HTTP server reading data 
from an SQLite database for display by web clients. Some tables are 
updated infrequently (minutes), but one contains current status of 
numerous machines, and it is written/read relatively frequently. Data is 
written to the DB by a dedicated writer thread. The frequently-written 
table is temporary  in the sense that it is dropped/created at run-time, 
and the data doesn't need to persist between executions.

My question is whether there is a way for this table to be in memory. 
Each thread has its own connection, which I understand to be necessary. 
Am I correct that this means they can't share an in-memory DB or an 
in-memory TEMP table, because those are restricted to a single 
connection? It's very convenient to use SQLite for this purpose because 
each client may be interested in a different row or set of rows from the 
"real-time" table, and it seems a shame for the shared data to have to 
be on disk and not simply in memory.

Thanks,

Joe

[sqlite] Please confirm what I THINK I know about blobs

[Eric Hill]

This approach:

CREATE TABLE blob_table (
  ModelNo TEXT,
  SerialNo TEXT,
  VSWR BLOB_DOUBLE
)

involves comments?  I don't see how.  Nothing wrong with the comments approach, 
but this is an approach that just takes advantage of the fact that SQLite does 
not have fixed data types.

Eric

From: Simon Slavin
Sent: ?Saturday?, ?May? ?9?, ?2015 ?3?:?52? ?PM
To: General Discussion of SQLite Database


On 9 May 2015, at 8:12pm, Drago, William @ CSG - NARDA-MITEQ  wrote:

> Best idea yet! Anyone see any issues with this?

It's actually a comment, and SQLite provides ways of putting proper comments in 
table definitions:

CREATE TABLE blob_table (
 ModelNo TEXT, -- new-style models as used from 2006 onwards
 SerialNo TEXT,
 VSWR BLOB -- array of ten double-length floats
)

These comments can be found if you look at the table definition in 
sqlite_master.

I've also seen SQL databases where the designer created an otherwise unused 
table to hold comments on every column, something like this:

CREATE TABLE _structure (
 tableName TEXT,
 columnName TEXT,
 introduced TEXT,
 variableType TEXT,
 theComments TEXT
)

'introduced' was the edit of their program which first used the column 
(equivalent to 'checkin' as used by the SQLite development team).  
'variableType' was not the SQL type but the type of variable in the programming 
language they were using the database with.  This helped because the language 
had numerous variable types and subtle bugs could be introduced if you, for 
example, stored a value from an unsigned integer then did maths on the value in 
a long integer.

Simon.
___
sqlite-users mailing list
sqlite-users at mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users