Preview: few brand new enhancements

[sandro furieri]

Hi List,

just a quick preview about several small enhancements that
will be supported by the next-to-come version (and already
supported by the code available from the Fossil repositories).

Supporting multiple SQL statements to
be executed in a single step (GUI)
-------------------------------------
there was an old user post suggesting to implement such
feature; please see:
https://groups.google.com/forum/#!searchin/spatialite-users/statements/spatialite-users/xDB2E15xfvk/mr89xP5m3iMJ

- an arbitrary number of individual SQL statements could
  now be executed in a single request
- in this case each single SQL statement *shall* be correctly
  terminated by a semi-colon (;)
- if some statement will return an error the whole block execution
  will immediately terminate.
- only the resultset returned by the very last statement will
  be shown on the GUI panel.


Detecting the CPU architecture effectively
supported by the currently used code (GUI/SQL)
------------------------------------------
this problem is rather relevant on Windows platforms,
where parallel 32 / 64 bit versions are available and
distinguishing the one from the other isn't always as
obvious and easy as it ought be.
 
now the intended Target CPU is clearly shown in the
"About Dialog" supported by the GUI.

and a new spatialite_target_cpu() SQL function is
now supported, thus allowing to directly query this
relevant information at run-time.


Establishing READ-ONLY connections (GUI)
----------------------------------------
As you surely know, SQLite doesn't really support concurrent
access to the same DB-file; when SQLite requires to perform
any WRITE operation affecting the DB-file an exclusive lock
will be created on the whole file, thus preventing any other
process to access the same file.
And consequently any attempt to open two different connections
sharing the same DB-file will easily create a race condition
where an endless sequence of "Database file is locked" messages
will frustrate any attempt of concurrent access.

PAY CLOSE ATTENTION: simply establishing a READ-ONLY mode
connection isn't enough in order to ensure real concurrency.
The "writer" process *should* even use a WAL journal in order
to effectively enable any other "reader" process to safely
access the same DB-file while some write operation is in
progress (may be requiring a very long time to complete).
WAL isn't the default journal mode supported by SQLite, so
the "writer" process is strictly required to execute the
following PRAGMA before starting any write operation:

PRAGMA journal_mode=WAL;

once this simple precaution has been applied, then many
other different processes can effectively share the same
DB-file by using a READ-ONLY connection.

bye Sandro