Re: [sqlite] CLI .parameter command observations/request

[Simon Slavin]

On 16 Aug 2019, at 4:40pm, Martin  wrote:

> select * from sqlite_parameters

You are expected to create this table yourself, either directly or by using one 
of the parameter commands.  See



This sequence works.  You should be able to use it to progress:

sqlite> .schema
sqlite> .param init
sqlite> .schema
CREATE TABLE temp.sqlite_parameters(
  key TEXT PRIMARY KEY,
  value ANY
) WITHOUT ROWID;
sqlite> .param list
sqlite> .param set nodeNum 67
sqlite> .param list
nodeNum 67
sqlite> SELECT * FROM temp.sqlite_parameters;
nodeNum|67
sqlite> SELECT * FROM sqlite_parameters;
nodeNum|67
sqlite> 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] Bug: LSM1 lsm1BestIndex() always chooses table scan

[James Kafader]

Hi SQLite devs,

I'd like to begin with a "thank you" for a great tool that we use every day
at Internet Archive.

We are currently considering SQLite's LSM engine (we are aware it is not
considered production quality) to implement a index server process that
will underpin the Wayback Machine's URL replay.

We would like to use SQLite with the LSM1 module loaded to be able to write
efficient SQL to look up key ranges; we currently use a mechanism very
similar to this (but slower and more unweildy!) to serve this large index
out of plain text files.

In building the LSM1 module I followed charles leifer's instructions here:
https://www.charlesleifer.com/blog/lsm-key-value-storage-in-sqlite3/

resulting in this approximate set of commands:
wget http://sqlite.org/src/tarball/version-3.29.0/sqlite-3.29.tar.gz
tar zxvf sqlite-3.29.tar.gz
cd sqlite/ext/lsm1
CFLAGS="-g -fPIC" TCCX="gcc -g -fPIC" make lsm.so

we then load the lsm module that compiles into a version-compatible SQLite
3:
sqlite3
sqlite> .load /var/tmp/sqlite/ext/lsm1/lsm
sqlite> .timer on
sqlite> create virtual table cdx using lsm1 ('/var/tmp/cdx.lsm', key, TEXT,
value);
# here we load some data from a CSV file, appx 3m records for testing
purposes
# then we query out the last record from the loaded data
sqlite> select key, value from cdx where key =
'151,65,166,108)/media/newmuseum/images/0/51927_ca_object_representations_media_1_medium.jpg
20121001214108';
# this operation takes about 2s (!) and raised our curiosity. After a lot
of testing, it became clear that it's doing a full table scan, despite the
fact that the LSM implementation should be able to seek to this key.

We think, after trying out a fix that line 845 of lsm_vtab.c contains a
bug. This line
  for(i=0; inConstraint && idxNum<16; i++, pConstraint++){
should perhaps be replaced by this line:
   for(i=0; inConstraint && idxNum>16; i++, pConstraint++){

whether or not that's the correct fix, it seems to be something close to
logic involving idxNum there; it might be that it should be set to 0 to
begin with rather than 99.

Thanks again! We will report any other bugs we uncover.

Best,
James Kafader
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

[sqlite] CLI .parameter command observations/request

[Martin]

Hi, first a thankyou to everyone who helped with my 'date check clause' post.

This time I am grappling with the precompiled CLI .parameter command.
(The first line in the param.cli file is .echo on)

SQLite version 3.29.0 2019-07-10 17:32:03
sqlite> .read param.cli
.tables
-- select * from sqlite_parameters ;
Error: near line 4: no such table: sqlite_parameters
.param init
.tables
select * from sqlite_parameters ;
-- table now exists but not visible, where is it?

.param set $s  'abc'
.param set $slist  'abc, def'
.param set :int1
.param set :real   1.2
.param set @datex  '2019-01-01'
.param set @date   date('2019-01-01')

select $s, $slist, :int, :real, @datex, @date ;
abc|abc, def|1|1.2|2017|2019-01-01

select 1 where instr($slist, 'def') > 0 ;
1
select 1 where '2019-01-01' = @date ;
1
.param unset @datex
.param clear
.param list
$s 'abc'
$slist 'abc, def'
:int   1
:real  1.2
@date  '2019-01-01'


Initial observations wrt .parameter command:
  * INIT  works but the temp.table is not visible
  (even though one can explicitly insert into and delete from it.)
  * SET   works but there is some kind of evaluation of the VALUE
  (see @datex and @date; '2019-01-01' arithmetically is 2017)
  * UNSET works just fine
  * LIST  works just fine
  * CLEAR does nothing at all

As a result:
  * I feel that section 16 of the CLI documentation should mention VALUE 
treatment.

Additionally, dare I suggest
  * that CLEAR be renamed to DROP (action 'drop table') and made to work
  * that UNSET be augmented to allow .parameter unset ALL
(ALL is not a valid parameter name; action being 'delete from')

I appreciate renaming clear to drop is probably a non-starter for compatibility.
On the other hand, clear currently does do nothing.

Otherwise, thanks to the development team for a tool that just gets better!
Regards, Martin.

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

Re: [sqlite] Schema updates across threads in WAL & multithread mode

[Ben Asher]

To clarify, we add a column on our writer connection, and then "SELECT *
FROM table" on the reader connection does not include the column that was
added.

Ben

On Fri, Aug 16, 2019 at 11:32 AM Ben Asher  wrote:

> Hi folks! We're running (sqlite 3.27.2) into an issue where we make a
> schema update (adding a column to a table) on our writer connection, but
> then the schema update isn't immediately available on the read-only
> connections that we use on other threads, which causes a crash in our
> application (app expects the column to exist at that point). I've verified
> that the column does indeed get added, and everything works fine after
> restarting the application (i.e. all connections loaded fresh pickup the
> schema update).
>
> Is there something we need to do proactively to ensure that schema update
> appears immediately from other threads?
>
> Some notes about our setup:
>
> sqlite 3.27.2
> Using multithread mode (SQLITE_OPEN_NOMUTEX)
> Using WAL mode
>
> Thanks!
>
> Ben
>


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

Re: [sqlite] Schema updates across threads in WAL & multithread mode

[Richard Hipp]

On 8/16/19, Ben Asher  wrote:
>
> Is there something we need to do proactively to ensure that schema update
> appears immediately from other threads?
>

When a database connection has a read transaction open, it continues
to see a snapshot of the database as it existed when the read
transaction was first opened.  Outside changes to the database,
including schema changes, are invisible to the connection holding the
transaction.  This is the "I" in "ACID".

As soon as you release the read transaction and start another, all
changes will immediately become visible.

If you are not deliberately holding a read transaction open, perhaps
you are doing so accidentally by failing to sqlite3_reset() or
sqlite3_finalize() a prepared statement.  You can perhaps figure out
which statement that is by running:

   SELECT sql FROM sqlite_stmt WHERE busy;


-- 
D. Richard Hipp
d...@sqlite.org
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Schema updates across threads in WAL & multithread mode

[Simon Slavin]

On 16 Aug 2019, at 7:32pm, Ben Asher  wrote:

> we make a
> schema update (adding a column to a table) on our writer connection

Can I ask the maximum number of columns you expect to exist in that table ?  
I'm working up to trying to convince you to add a row to something instead, but 
I want to make sure you're doing what I think you're doing.

Other people may be able to answer your question.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Determining column collating functions

[Thomas Kurz]

Would you consider implementing this not as a pragma, but as a real statement, 
like MySQL's SHOW COLUMNS 
(https://dev.mysql.com/doc/refman/5.5/en/show-columns.html)? Would be easier to 
memorize.

- Original Message - 
From: Keith Medcalf 
To: SQLite mailing list 
Sent: Wednesday, August 14, 2019, 00:36:07
Subject: [sqlite] Determining column collating functions


On Tuesday, 13 August, 2019 15:59, Manuel Rigger  
wrote:

>Is there a simple way to determine the collating function of a
>column?

Presently, there is not.

>PRAGMA table_info does not seem to provide this information. The
>information could be extracted from sqlite_master, which contains the
>SQL statements used to create the table or view. While parsing the
>SQL string is rather straightforward for tables, it would involve 
>more effort to determine the collating functions for views, which 
>can again reference other views or tables.

The internal schema representation for the column (from which the table_info 
and table_xinfo draw their information) does contain the name of the collation 
being used if it is not the default (and also the actual affinity of the 
column), however the current table_info/table_xinfo does not return that 
information, although modifications to do so would be rather trivial.

Richard, would you like a patch for this (and a database_info pragma, which 
would allow all the introspection pragma tables to work across all attached 
databases more easily)?

As for views, they are a sort of dynamic thing so the collating sequence (nor 
the affinity) of a view column is not known until the statement using the view 
is prepared (a view is merely the storage of a definition and nothing is really 
known about it until it is used).

-- 
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.





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

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

Re: [sqlite] Backward compatibility vs. new features (was: Re: dates, times and R)

[Thomas Kurz]

Another reason: because PostgreSQL supports it as well (including timezone) ;-)

- Original Message - 
From: Peter da Silva 
To: SQLite mailing list 
Sent: Tuesday, August 13, 2019, 23:18:29
Subject: [sqlite] Backward compatibility vs. new features (was: Re: dates, 
times and R)

If the datr/time is stored internally as utc iso8601 text then it will
remain compatible with old versions and can implement whatever new behavior
is needed on new versions. The bigger question is 'what new behavior'? The
only nee behavior seems to be 'let this third party package see it as a
date', which it should be able to figure out by looking at the schema.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

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

Re: [sqlite] Schema updates across threads in WAL & multithread mode

[Jose Isaias Cabrera]

Ben Asher, on Friday, August 16, 2019 02:32 PM, wrote...
>
> Hi folks! We're running (sqlite 3.27.2) into an issue where we make a
> schema update (adding a column to a table) on our writer connection, but
> then the schema update isn't immediately available on the read-only
> connections that we use on other threads, which causes a crash in our
> application (app expects the column to exist at that point). I've verified
> that the column does indeed get added, and everything works fine after
> restarting the application (i.e. all connections loaded fresh pickup the
> schema update).
>
> Is there something we need to do proactively to ensure that schema update
> appears immediately from other threads?

Are you using BEGIN and END before and after the schema update?

josé
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Getting a notification when a write lock is released.

[Jose Isaias Cabrera]

test user, on Friday, August 16, 2019 02:29 PM, wrote...
>
> Thanks for the example José.
You're welcome.  Just thought I would provide some idea... :-)

josé


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

[sqlite] Schema updates across threads in WAL & multithread mode

[Ben Asher]

Hi folks! We're running (sqlite 3.27.2) into an issue where we make a
schema update (adding a column to a table) on our writer connection, but
then the schema update isn't immediately available on the read-only
connections that we use on other threads, which causes a crash in our
application (app expects the column to exist at that point). I've verified
that the column does indeed get added, and everything works fine after
restarting the application (i.e. all connections loaded fresh pickup the
schema update).

Is there something we need to do proactively to ensure that schema update
appears immediately from other threads?

Some notes about our setup:

sqlite 3.27.2
Using multithread mode (SQLITE_OPEN_NOMUTEX)
Using WAL mode

Thanks!

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

Re: [sqlite] Getting a notification when a write lock is released.

[test user]

Thanks for the example José.

I was thinking of a more general method that would work when I do not
control all of the clients.

Your example would only work when all clients are aware of and use the
locking logic.





On Fri, Aug 16, 2019 at 3:39 PM Jose Isaias Cabrera 
wrote:

>
> test user, on Thursday, August 15, 2019 07:35 PM, wrote...
>
> > The reason for the notification is to minimize time spent waiting.
>
> I will tell you what I did with 10 PMs working with a shared windows drive
> with an SQLite DB. But, take it with a grain of salt, unless you have
> high-blood pressure, which if it is so, may suggest a salt substitute? :-)
>
> Before every write to the DB, I would call a function that would check if
> someone was writing to the DB:
>
>   while (SharedDBBlocked(false))
> std.c.time.msleep(500); // waits 1/2 second
>
> This is what SharedDBBlocked did...
>
> char[] SharedDBBlocked(bool ShowMsgBox)
> {
>   char[] ttdir = std.path.getDirName(sqldb);  // =
> r"L:\Data\OpenJobsTool\AllOpenProjs.db";
>   ttdir = ttdir ~ "\\" ~ "dbLockedBy.txt";// checks for a file in the
> same spot where the sharedDB is
>   char[] who = null;
>   if (std.file.exists(ttdir))  // someone is writing to the DB
>   {
> try
> {
>   who = cast(char[]) ttdir.read();
> }
> catch (FileException e)
> {
>   return who;
> }
> if (who == pm["FirstName"])  // The PMs lack of patience (3-10
> seconds). Long story.
> {
>   if (DeleteFile(ttdir, eStr))
> info.text = ttdir[std.string.rfind(ttdir,r"\") .. $] ~ " file
> deleted.";
>   return null;
> }
> else
> {
>   char[] t = who ~ " is writing to the SharedDB.  Waiting for
> release...";
>   error.text = t;
>   if (ShowMsgBox)
> msgBox(t);
>   return who;
> }
>   }
>   return who;
> }
>
> Once this was DB was release, you would call for,
>
>   LockDBForDataWriting();
>
> to take control of the DB.  This is what it contains...
>
> char[] LockDBForDataWriting()
> {
>   while (SharedDBBlocked(false))  //check again to make sure...
> std.c.time.msleep(1500);
>   error.text = "";
>   char[] ttdir = std.path.getDirName(sqldba);   // =
> r"L:\Data\OpenJobsTool\AllOpenProjs.db";
>   ttdir = ttdir ~ "\\dbLockedBy.txt";
>   char[] t = "";;
>   if (!std.file.exists(ttdir))
>   {
> try
> {
>   ttdir.write(pm["FirstName"]);
>   t = pm["FirstName"];
> }
> catch (FileException e)
> {
>   ttdir.write(GetUserName());
>   t = GetUserName();
> }
>   }
>   return t;
> }
>
> Once you have control, do some work on the DB...
>
>   string q = "INSERT ...; ";
>   try
>   {
> wdb.execute(q);
>   }
>   catch (DBIException dbe)
>   {
> UnLockDBForDataWriting();
> msgBox("ERR605: Could not ...:" ~ dbe.toString());
> return 1;
>   }
>
>   UnLockDBForDataWriting();
>   return 0;
>
> And that is it.  Of course, this is a primitive and slow way of doing it,
> but these were inpatient PMs, and it worked for a long time. If your
> writters are not human, the wait times could be lowered and it would be
> made faster.  Just FYI.  Thanks.
>
> josé
>
>
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] Getting a notification when a write lock is released.

[Jose Isaias Cabrera]

test user, on Thursday, August 15, 2019 07:35 PM, wrote...

> The reason for the notification is to minimize time spent waiting.

I will tell you what I did with 10 PMs working with a shared windows drive with 
an SQLite DB. But, take it with a grain of salt, unless you have high-blood 
pressure, which if it is so, may suggest a salt substitute? :-)

Before every write to the DB, I would call a function that would check if 
someone was writing to the DB:

  while (SharedDBBlocked(false))
std.c.time.msleep(500); // waits 1/2 second

This is what SharedDBBlocked did...

char[] SharedDBBlocked(bool ShowMsgBox)
{
  char[] ttdir = std.path.getDirName(sqldb);  // = 
r"L:\Data\OpenJobsTool\AllOpenProjs.db";
  ttdir = ttdir ~ "\\" ~ "dbLockedBy.txt";// checks for a file in the same 
spot where the sharedDB is
  char[] who = null;
  if (std.file.exists(ttdir))  // someone is writing to the DB
  {
try
{
  who = cast(char[]) ttdir.read();
}
catch (FileException e)
{
  return who;
}
if (who == pm["FirstName"])  // The PMs lack of patience (3-10 seconds). 
Long story.
{
  if (DeleteFile(ttdir, eStr))
info.text = ttdir[std.string.rfind(ttdir,r"\") .. $] ~ " file deleted.";
  return null;
}
else
{
  char[] t = who ~ " is writing to the SharedDB.  Waiting for release...";
  error.text = t;
  if (ShowMsgBox)
msgBox(t);
  return who;
}
  }
  return who;
}

Once this was DB was release, you would call for,

  LockDBForDataWriting();

to take control of the DB.  This is what it contains...

char[] LockDBForDataWriting()
{
  while (SharedDBBlocked(false))  //check again to make sure...
std.c.time.msleep(1500);
  error.text = "";
  char[] ttdir = std.path.getDirName(sqldba);   // = 
r"L:\Data\OpenJobsTool\AllOpenProjs.db";
  ttdir = ttdir ~ "\\dbLockedBy.txt";
  char[] t = "";;
  if (!std.file.exists(ttdir))
  {
try
{
  ttdir.write(pm["FirstName"]);
  t = pm["FirstName"];
}
catch (FileException e)
{
  ttdir.write(GetUserName());
  t = GetUserName();
}
  }
  return t;
}

Once you have control, do some work on the DB...

  string q = "INSERT ...; ";
  try
  {
wdb.execute(q);
  }
  catch (DBIException dbe)
  {
UnLockDBForDataWriting();
msgBox("ERR605: Could not ...:" ~ dbe.toString());
return 1;
  }

  UnLockDBForDataWriting();
  return 0;

And that is it.  Of course, this is a primitive and slow way of doing it, but 
these were inpatient PMs, and it worked for a long time. If your writters are 
not human, the wait times could be lowered and it would be made faster.  Just 
FYI.  Thanks.

josé


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

Re: [sqlite] [EXTERNAL] Re: Documentation update request

[Kevin Benson]

On Fri, Aug 16, 2019 at 3:15 AM Hick Gunter  wrote:

> Reminds me of "... two mice ran up the clock, the clock struck one, and
> the other escaped with minor injuries"
>

'Twas my impetus (rather than the wording that mistakenly sounded like I
was "besmirching" Dr. Hipp)


>
> -Ursprüngliche Nachricht-
> Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org]
> Im Auftrag von Kevin Benson
> Gesendet: Donnerstag, 15. August 2019 20:40
> An: SQLite mailing list 
> Betreff: [EXTERNAL] Re: [sqlite] Documentation update request
>
> On Thu, Aug 15, 2019 at 2:33 PM Jose Isaias Cabrera 
> wrote:
>
> > Richard Hipp, on Thursday, August 15, 2019 01:32 PM, wrote...
> > >
> > > On 8/15/19, Simon Slavin, on
> > > > On 15 Aug 2019, at 5:20pm, Richard Damon, on
> > > >
> > > >> You under quote, the faq says it “can not be changed (except
> > > >> under extra-ordinary conditions).”, and those extra-ordinary
> > > >> conditions are
> > a
> > > >> link to the second section you mention.
> > > >
> > > > I didn't notice that, for some reason.  Thanks for the correction.
> > >
> > > You didn't notice it because I only added it moments ago, in
> > > response to your documentation update request.
> >
> > Oh! Trickery!
> >
> >
> Dickery (sometimes a nickname for RICHARD ;-)

Doc (...umentation; the something Richard "Dick" Hipp was doing ;-)
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [EXTERNAL] Re: Getting a notification when a write lock is released.

[Hick Gunter]

Maybe you are looking for semaphores. These can be tricky to use correctly in 
the case of cooperating processes, where you have to handle the case of the 
current owner of the semaphore terminating within the monitored section of code.

-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von test user
Gesendet: Freitag, 16. August 2019 01:35
An: SQLite mailing list 
Betreff: [EXTERNAL] Re: [sqlite] Getting a notification when a write lock is 
released.

Thanks Simon,


> You can use any other combination that suits you.  Perhaps set a short
> timeout, after which SQLite calls your busy handler, which can do
> whatever it wants then return SQLITE_BUSY to your program.  When the
> short timeout gets exhausted, SQLite calls your own busy handler, and
> /that's/ your notification.
>


> None of these would use the hint system or try to monitor files directly.
> As you see, there's an existing way to monitor locks.  You don't need
> to abuse a different notification which isn't really suited to this purpose.



The reason for the notification is to minimize time spent waiting.

Lets say you can categorize the time spent waiting for a lock into these
sets:

- A. Time waiting whilst lock is locked.
- B. Time waiting whilst lock is unlocked.


With the current locking system, if you have many processes contending for 
write locks, time spent in set B will be > 0.

With a notification when the lock is released, B can equal 0 for the duration 
of the system uptime.

I understand the current lock system works well, and that this is a more 
complex system.


Regarding your short timeout suggestion: Is polling the lock frequently in very 
short intervals resource intensive?


Is SQLITE_ENABLE_SETLK_TIMEOUT the best way to try and implement this in my own 
library?


On Thu, Aug 15, 2019 at 11:08 PM Simon Slavin  wrote:

> On 15 Aug 2019, at 10:43pm, test user 
> wrote:
>
> > Currently the API lets you set a timeout. Does this just retry again
> after a set amount of time?
>
> SQLite's built-in busy handler (which it uses unless you tell it to
> use yours instead) repeatedly backs off and retries until the timeout
> you set is complete.  The amount of time it backs off for is decided
> internally and you cannot depend on it being the same amount of time
> every time.  The entire time the busy handler takes should never much
> exceed the amount of time you set as your timeout.
>
> > But I was thinking more along the lines of keeping BUSY and the
> > current
> locking system as is, but using the notification as a hint, that is
> possibly unreliable.
> >
> > E.g. if BUSY (try again (after x seconds OR when hint arrives))
>
> The assumption behind SQLite is that you will do one of three things.
> The first of them is what most users do:
>
> 1) Set a long timeout, but not set your own busy handler.  Then let
> SQLite handle the wait-and-retry loop until it finally gives up and
> returns SQLITE_BUSY.  Then your program announces that the database is
> inaccessible and quits (or gives up that function).
>
> 2) Set no timeout and no busy handler.  Receive and handle SQLITE_BUSY
> by doing whatever the program finds suitable.  Perhaps implement your
> own wait-and-retry loop, perhaps do something a lot more
> sophisticated, appropriate to whatever the user expects.
>
> 3) Set no timeout and implement your own busy handler.
>
> You can use any other combination that suits you.  Perhaps set a short
> timeout, after which SQLite calls your busy handler, which can do
> whatever it wants then return SQLITE_BUSY to your program.  When the
> short timeout gets exhausted, SQLite calls your own busy handler, and
> /that's/ your notification.
>
> None of these would use the hint system or try to monitor files directly.
> As you see, there's an existing way to monitor locks.  You don't need
> to abuse a different notification which isn't really suited to this purpose.
> ___
> sqlite-users mailing list
> sqlite-users@mailinglists.sqlite.org
> http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
 Gunter Hick | Software Engineer | Scientific Games International GmbH | 
Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 
1 80100 - 0

May be privileged. May be confidential. Please delete if not the addressee.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users

Re: [sqlite] [EXTERNAL] Re: Documentation update request

[Hick Gunter]

Reminds me of "... two mice ran up the clock, the clock struck one, and the 
other escaped with minor injuries"

-Ursprüngliche Nachricht-
Von: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] Im 
Auftrag von Kevin Benson
Gesendet: Donnerstag, 15. August 2019 20:40
An: SQLite mailing list 
Betreff: [EXTERNAL] Re: [sqlite] Documentation update request

On Thu, Aug 15, 2019 at 2:33 PM Jose Isaias Cabrera 
wrote:

> Richard Hipp, on Thursday, August 15, 2019 01:32 PM, wrote...
> >
> > On 8/15/19, Simon Slavin, on
> > > On 15 Aug 2019, at 5:20pm, Richard Damon, on
> > >
> > >> You under quote, the faq says it “can not be changed (except
> > >> under extra-ordinary conditions).”, and those extra-ordinary
> > >> conditions are
> a
> > >> link to the second section you mention.
> > >
> > > I didn't notice that, for some reason.  Thanks for the correction.
> >
> > You didn't notice it because I only added it moments ago, in
> > response to your documentation update request.
>
> Oh! Trickery!
>
>
Dickery (sometimes a nickname for RICHARD ;-) Doc (...umentation; the something 
Richard "Dick" Hipp was doing ;-) 
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users


___
 Gunter Hick | Software Engineer | Scientific Games International GmbH | 
Klitschgasse 2-4, A-1130 Vienna | FN 157284 a, HG Wien, DVR: 0430013 | (O) +43 
1 80100 - 0

May be privileged. May be confidential. Please delete if not the addressee.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users