bBox_SQLiteOpen( path {; options} )

Parameters:
   path:
      use ":memory" for in-memory storage without a file
      POSIX path can be used to specify a file system location (eg, /tmp/mysqlite.db)
      use "" (empty string) to use a temporary, private file for storage
   options: space delimited list of zero or more SQLITE_OPEN options

Result:
   positive number indicates success, and is the session ID

Error:
   bBox_LastError ($reference)

Script Step:
none

––––––––––

First appeared in: 0.80 (will be replaced with bBox_DuckDBOpen in version 1.05)

Examples in demo file: 

Compatibility: Client, macOS, Server, Ubuntu, WebDirect, WPE

––––––––––

Creates a new SQLite3 session at the given SQLite3 path for later use with bBox_SQLiteExec.

You will need to save the returned reference value for later calls to bBox_SQLiteExec and bBox_SQLiteClose.

The default options are READWRITE + CREATE. Otherwise, either READWRITE or READONLY are typical. These correlate to the constants as defined in the SQLite3 C++ interface that begin with SQLITE_OPEN_.

The SQLite3 library used is compiled with the SQLITE_CONFIG_MULTITHREAD option set. This means that each PSoS script may open its own files, or even the same file already in use by another PSoS instance (check for temporary write locks if updating), but it should not share references across PSoS instances unless you can guarantee that each PSoS instance will not use the same connection at the same time.

A common error is #14, "unable to open database file", which is often due to file permissions preventing write access or a bad path.