text:
Artifact eebb8f2c0da89f277069fa398a3137a5cf1e6c70258e9567b1497cddf4f7bdb7:
- File pages/compile.in — part of check-in [f49396b55b] at 2018-03-08 00:33:08 on branch trunk — Add the documentation about SQLite Archive files. Updates to the change log. (user: drh size: 80399)
<title>Compile-time Options</title> <tcl>hd_keywords {compile-time options}</tcl> <table_of_contents>
Overview

 For most purposes, SQLite can be built just fine using the default compilation options. However, if required, the compile-time options documented below can be used to omit SQLite features (resulting in a [relfootprint | smaller compiled library size]) or to change the default values of some parameters.

 Every effort has been made to ensure that the various combinations of compilation options work harmoniously and produce a working library. Nevertheless, it is strongly recommended that the SQLite test-suite be executed to check for errors before using an SQLite library built with non-standard compilation options.
 <tcl> proc COMPILE_OPTION {name text} { if {[regexp {(SQLITE|HAVE)_([A-Z0-9_]+)} $name all prefix label]} { hd_fragment [string tolower $label] hd_keywords $all -D$all } if {[regexp {^YY([A-Z0-9_]+)} $name all label]} { hd_fragment [string tolower $all] hd_keywords $all } hd_puts
$name
 regsub -all "\n\\s*\n" $text "
\n\n
" text hd_resolve

$text

 } hd_fragment rcmd {recommended compile-time options} </tcl>
Recommended Compile-time Options

The following compile-time options are recommended for applications that are able to use them, in order to minimized the number of CPU cycles and the bytes of memory used by SQLite. Not all of these compile-time options are usable by every application. For example, the SQLITE_THREADSAFE=0 option is only usable by applications that never access SQLite from more than one thread at a time. And the SQLITE_OMIT_PROGRESS_CALLBACK option is only usable by applications that doe not use the [sqlite3_progress_handler()] interface. And so forth.
It is impossible to test every possible combination of compile-time options for SQLite. But the following set of compile-time options is one configuration that is always fully tested.

[SQLITE_THREADSAFE=0]. Setting -DSQLITE_THREADSAFE=0 causes all of the mutex and thread-safety logic in SQLite to be omitted. This is the single compile-time option that makes the most difference in optimizing the performance of SQLite.

[SQLITE_DEFAULT_MEMSTATUS=0]. This setting causes the [sqlite3_status()] interfaces that track memory usage to be disabled. This helps the [sqlite3_malloc()] routines run much faster, and since SQLite uses [sqlite3_malloc()] internally, this helps to make the entire library faster.

[SQLITE_DEFAULT_WAL_SYNCHRONOUS=1]. For maximum database safety following a power lose, the setting of [PRAGMA synchronous=FULL] is recommended. However, in [WAL mode], complete database integrity is guaranteed with [PRAGMA synchronous=NORMAL]. With [PRAGMA synchronous=NORMAL] in [WAL mode], recent changes to the database might be rolled back by a power loss, but the database will not be corrupted. Furthermore, transaction commit is much faster in WAL mode using synchronous=NORMAL than with the default synchronous=FULL. For these reasons, it is recommended that the synchronous setting be changed from FULL to NORMAL when switching to WAL mode. This compile-time option will accomplish that.

[SQLITE_LIKE_DOESNT_MATCH_BLOBS]. Historically, SQLite has allowed BLOB operands to the [LIKE] and [GLOB] operators. But having a BLOB as an operand of [LIKE] or [GLOB] complicates and slows the [LIKE optimization]. When this option is set, it means that the LIKE and GLOB operators always return FALSE if either operand is a BLOB. That simplifies the implementation of the [LIKE optimization] and allows queries that use the [LIKE optimization] to run faster.

[SQLITE_MAX_EXPR_DEPTH=0]. Setting the maximum expression parse-tree depth to zero disables all checking of the expression parse-tree depth, which simplifies the code resulting in faster execution, and helps the parse tree to use less memory.

[SQLITE_OMIT_DECLTYPE]. By omitting the (seldom-needed) ability to return the declared type of columns from the result set of query, [prepared statements] can be made to consume less memory.

[SQLITE_OMIT_DEPRECATED]. Omitting deprecated interfaces and features will not help SQLite to run any faster. It will reduce the library footprint, however. And it is the right thing to do.

[SQLITE_OMIT_PROGRESS_CALLBACK]. The progress handler callback counter must be checked in the inner loop of the [bytecode engine]. By omitting this interface, a single conditional is removed from the inner loop of the [bytecode engine], helping SQL statements to run slightly faster.

[SQLITE_OMIT_SHARED_CACHE]. Omitting the possibility of using [shared cache] allows many conditionals in performance-critical sections of the code to be eliminated. This can give a noticable improvement in performance.

[SQLITE_USE_ALLOCA]. Make use of alloca() for dynamically allocating temporary stack space for use within a single function, on systems that support alloca(). Without this option, temporary space is allocated from the heap.

When all of the recommended compile-time options above are used, the SQLite library will be approximately 3% smaller and use about 5% fewer CPU cycles. So these options do not make a huge difference. But in some design situations, every little bit helps.
 Platform Configuration
 <tcl> COMPILE_OPTION {_HAVE_SQLITE_CONFIG_H} { If the _HAVE_SQLITE_CONFIG_H macro is defined then the SQLite source code will attempt to #include a file named "config.h". The "config.h" file usually contains other configuration options, especially "HAVE_INTERFACE" type options generated by autoconf scripts. } COMPILE_OPTION {HAVE_FDATASYNC} { If the HAVE_FDATASYNC compile-time option is true, then the default [VFS] for unix systems will attempt to use fdatasync() instead of fsync() where appropriate. If this flag is missing or false, then fsync() is always used. } COMPILE_OPTION {HAVE_GMTIME_R} { If the HAVE_GMTIME_R option is true and if [SQLITE_OMIT_DATETIME_FUNCS] is true, then the CURRENT_TIME, CURRENT_DATE, and CURRENT_TIMESTAMP keywords will use the threadsafe "gmtime_r()" interface rather than "gmtime()". In the usual case where [SQLITE_OMIT_DATETIME_FUNCS] is not defined or is false, then the built-in [date and time functions] are used to implement the CURRENT_TIME, CURRENT_DATE, and CURRENT_TIMESTAMP keywords and neither gmtime_r() nor gmtime() is ever called. } COMPILE_OPTION {HAVE_ISNAN} { If the HAVE_ISNAN option is true, then SQLite invokes the system library isnan() function to determine if a double-precision floating point value is a NaN. If HAVE_ISNAN is undefined or false, then SQLite substitutes its own home-grown implementation of isnan(). } COMPILE_OPTION {HAVE_LOCALTIME_R} { If the HAVE_LOCALTIME_R option is true, then SQLite uses the threadsafe localtime_r() library routine instead of localtime() to help implement the [localtime modifier] to the built-in [date and time functions]. } COMPILE_OPTION {HAVE_LOCALTIME_S} { If the HAVE_LOCALTIME_S option is true, then SQLite uses the threadsafe localtime_s() library routine instead of localtime() to help implement the [localtime modifier] to the built-in [date and time functions]. } COMPILE_OPTION {HAVE_MALLOC_USABLE_SIZE} { If the HAVE_MALLOC_USABLE_SIZE option is true, then SQLite tries uses the malloc_usable_size() interface to find the size of a memory allocation obtained from the standard-library malloc() or realloc() routines. This option is only applicable if the standard-library malloc() is used. On Apple systems, "zone malloc" is used instead, and so this option is not applicable. And, of course, if the application supplies its own malloc implementation using [SQLITE_CONFIG_MALLOC] then this option has no effect.
 If the HAVE_MALLOC_USABLE_SIZE option is omitted or is false, then SQLite uses a wrapper around system malloc() and realloc() that enlarges each allocation by 8 bytes and writes the size of the allocation in the initial 8 bytes, and then SQLite also implements its own home-grown version of malloc_usable_size() that consults that 8-byte prefix to find the allocation size. This approach works but it is suboptimal. Applications are encouraged to use HAVE_MALLOC_USABLE_SIZE whenever possible. } COMPILE_OPTION {HAVE_STRCHRNUL} { If the HAVE_STRCHRNUL option is true, then SQLite uses the strchrnul() library function. If this option is missing or false, then SQLite substitutes its own home-grown implementation of strchrnul(). } COMPILE_OPTION {HAVE_USLEEP} { If the HAVE_USLEEP option is true, then the default unix VFS uses the usleep() system call to implement the xSleep method. If this option is undefined or false, then xSleep on unix is implemented using sleep() which means that [sqlite3_sleep()] will have a minimum wait interval of 1000 milliseconds regardless of its argument. } COMPILE_OPTION {HAVE_UTIME} { If the HAVE_UTIME option is true, then the built-in but non-standard "unix-dotfile" VFS will use the utime() system call, instead of utimes(), to set the last access time on the lock file. } COMPILE_OPTION {SQLITE_BYTEORDER=(0|1234|4321)} { SQLite needs to know if the native byte order of the target CPU is big-endian or little-ending. The SQLITE_BYTEORDER preprocessor is set to 4321 for big-endian machines and 1234 for little-endian machines, or it can be 0 to mean that the byte order must be determined at run-time. There are #ifdefs in the code that set SQLITE_BYTEORDER automatically for all common platforms and compilers. However, it may be advantageous to set SQLITE_BYTEORDER appropriately when compiling SQLite for obscure targets. If the target byte order cannot be determined at compile-time, then SQLite falls back to doing run-time checks, which always work, though with a small performance penalty. } </tcl>
 Options To Set Default Parameter Values
 <tcl> COMPILE_OPTION {SQLITE_DEFAULT_AUTOMATIC_INDEX=<0 or 1>} { This macro determines the initial setting for [PRAGMA automatic_index] for newly opened [database connections]. For all versions of SQLite through 3.7.17, automatic indices are normally enabled for new database connections if this compile-time option is omitted. However, that might change in future releases of SQLite.
See also: [SQLITE_OMIT_AUTOMATIC_INDEX] } COMPILE_OPTION {SQLITE_DEFAULT_AUTOVACUUM=<0 or 1 or 2>} { This macro determines if SQLite creates databases with the [auto_vacuum] flag set by default to OFF (0), FULL (1), or INCREMENTAL (2). The default value is 0 meaning that databases are created with auto-vacuum turned off. In any case the compile-time default may be overridden by the [PRAGMA auto_vacuum] command. } COMPILE_OPTION {SQLITE_DEFAULT_CACHE_SIZE=<N>} { This macro sets the default maximum size of the page-cache for each attached database. A positive value means that the limit is N page. If N is negative that means to limit the cache size to -N*1024 bytes. The suggested maximum cache size can be overridden by the [PRAGMA cache_size] command. The default value is -2000, which translates into a maximum of 2048000 bytes per cache. } COMPILE_OPTION {SQLITE_DEFAULT_FILE_FORMAT=<1 or 4>} { The default [schema format number] used by SQLite when creating new database files is set by this macro. The schema formats are all very similar. The difference between formats 1 and 4 is that format 4 understands [descending indices] and has a tighter encoding for boolean values. All versions of SQLite since 3.3.0 (2006-01-10) can read and write any schema format between 1 and 4. But older versions of SQLite might not be able to read formats greater than 1. So that older versions of SQLite will be able to read and write database files created by newer versions of SQLite, the default schema format was set to 1 for SQLite versions through 3.7.9 (2011-11-01). Beginning with [version 3.7.10] ([dateof:3.7.10]), the default schema format is 4. The schema format number for a new database can be set at runtime using the [PRAGMA legacy_file_format] command. } COMPILE_OPTION {SQLITE_DEFAULT_FILE_PERMISSIONS=N} { The default numeric file permissions for newly created database files under unix. If not specified, the default is 0644 which means that the files is globally readable but only writable by the creator. } COMPILE_OPTION {SQLITE_DEFAULT_FOREIGN_KEYS=<0 or 1>} { This macro determines whether enforcement of [foreign key constraints] is enabled or disabled by default for new database connections. Each database connection can always turn enforcement of foreign key constraints on and off and run-time using the [foreign_keys pragma]. Enforcement of foreign key constraints is normally off by default, but if this compile-time parameter is set to 1, enforcement of foreign key constraints will be on by default. } COMPILE_OPTION {SQLITE_DEFAULT_MMAP_SIZE=N} { This macro sets the default limit on the amount of memory that will be used for memory-mapped I/O for each open database file. If the N is zero, then memory mapped I/O is disabled by default. This compile-time limit and the [SQLITE_MAX_MMAP_SIZE] can be modified at start-time using the [sqlite3_config]([SQLITE_CONFIG_MMAP_SIZE]) call, or at run-time using the [mmap_size pragma]. } COMPILE_OPTION {SQLITE_DEFAULT_JOURNAL_SIZE_LIMIT=<bytes>} { This option sets the size limit on [rollback journal] files in [journal_mode pragma | persistent journal mode] and [locking_mode | exclusive locking mode] and on the size of the write-ahead log file in [WAL mode]. When this compile-time option is omitted there is no upper bound on the size of the rollback journals or write-ahead logs. The journal file size limit can be changed at run-time using the [journal_size_limit pragma]. } COMPILE_OPTION {SQLITE_DEFAULT_LOCKING_MODE=<1 or 0>} { If set to 1, then the default [locking_mode] is set to EXCLUSIVE. If omitted or set to 0 then the default [locking_mode] is NORMAL. } COMPILE_OPTION {SQLITE_DEFAULT_LOOKASIDE=SZ,N} { Sets the default size of the [lookaside memory allocator] memory pool to N entries of SZ bytes each. This setting can be modified at start-time using [sqlite3_config]([SQLITE_CONFIG_LOOKASIDE]) and/or as each [database connection] is opened using [sqlite3_db_config](db, [SQLITE_DBCONFIG_LOOKASIDE]). } COMPILE_OPTION {SQLITE_DEFAULT_MEMSTATUS=<1 or 0>} { This macro is used to determine whether or not the features enabled and disabled using the SQLITE_CONFIG_MEMSTATUS argument to [sqlite3_config()] are available by default. The default value is 1 ([SQLITE_CONFIG_MEMSTATUS] related features enabled).
 The [sqlite3_memory_used()] and [sqlite3_memory_highwater()] interfaces, the [sqlite3_status64]([SQLITE_STATUS_MEMORY_USED]) interface, and the [SQLITE_MAX_MEMORY] compile-time option are all non-functional when memory usage tracking is disabled. } COMPILE_OPTION {SQLITE_DEFAULT_PCACHE_INITSZ=N} { This macro determines the number of pages initially allocated by the page cache module when [SQLITE_CONFIG_PAGECACHE] configuration option is not use and memory for the page cache is obtained from [sqlite3_malloc()] instead. The number of pages set by this macro are allocated in a single allocation, which reduces the load on the memory allocator. } COMPILE_OPTION {SQLITE_DEFAULT_PAGE_SIZE=<bytes>} { This macro is used to set the default page-size used when a database is created. The value assigned must be a power of 2. The default value is 4096. The compile-time default may be overridden at runtime by the [PRAGMA page_size] command. } COMPILE_OPTION {SQLITE_DEFAULT_SYNCHRONOUS=<0-3>} { This macro determines the default value of the [PRAGMA synchronous] setting. If not overridden at compile-time, the default setting is 2 (FULL). } COMPILE_OPTION {SQLITE_DEFAULT_WAL_SYNCHRONOUS=<0-3>} { This macro determines the default value of the [PRAGMA synchronous] setting for database files that open in [WAL mode]. If not overridden at compile-time, this value is the same as [SQLITE_DEFAULT_SYNCHRONOUS].
 If SQLITE_DEFAULT_WAL_SYNCHRONOUS differs from SQLITE_DEFAULT_SYNCHRONOUS, and if the application has not modified the synchronous setting for the database file using the [PRAGMA synchronous] statement, then the synchronous setting is changed to value defined by SQLITE_DEFAULT_WAL_SYNCHRONOUS when the database connection switches into WAL mode for the first time. If the SQLITE_DEFAULT_WAL_SYNCHRONOUS value is not overridden at compile-time, then it will always be the same as [SQLITE_DEFAULT_SYNCHRONOUS] and so no automatic synchronous setting changes will ever occur. } COMPILE_OPTION {SQLITE_DEFAULT_WAL_AUTOCHECKPOINT=<pages>} { This macro sets the default page count for the [WAL] [checkpointing | automatic checkpointing] feature. If unspecified, the default page count is 1000. } COMPILE_OPTION {SQLITE_DEFAULT_WORKER_THREADS=N} { This macro sets the default value for the [SQLITE_LIMIT_WORKER_THREADS] parameter. The [SQLITE_LIMIT_WORKER_THREADS] parameter sets the maximum number of auxiliary threads that a single [prepared statement] will launch to assist it with a query. If not specified, the default maximum is 0. The value set here cannot be more than [SQLITE_MAX_WORKER_THREADS]. } COMPILE_OPTION {SQLITE_EXTRA_DURABLE} { The SQLITE_EXTRA_DURABLE compile-time option that used to cause the default [PRAGMA synchronous] setting to be EXTRA, rather than FULL. This option is no longer supported. Use [SQLITE_DEFAULT_SYNCHRONOUS|SQLITE_DEFAULT_SYNCHRONOUS=3] instead. } COMPILE_OPTION {SQLITE_FTS3_MAX_EXPR_DEPTH=N} { This macro sets the maximum depth of the search tree that corresponds to the right-hand side of the MATCH operator in an [FTS3] or [FTS4] full-text index. The full-text search uses a recursive algorithm, so the depth of the tree is limited to prevent using too much stack space. The default limit is 12. This limit is sufficient for up to 4095 search terms on the right-hand side of the MATCH operator and it holds stack space usage to less than 2000 bytes.
 For ordinary FTS3/FTS4 queries, the search tree depth is approximately the base-2 logarithm of the number of terms in the right-hand side of the MATCH operator. However, for [phrase queries] and [NEAR queries] the search tree depth is linear in the number of right-hand side terms. So the default depth limit of 12 is sufficient for up to 4095 ordinary terms on a MATCH, it is only sufficient for 11 or 12 phrase or NEAR terms. Even so, the default is more than enough for most application. } COMPILE_OPTION {SQLITE_LIKE_DOESNT_MATCH_BLOBS} { This compile-time option causes the [LIKE] operator to always return False if either operand is a BLOB. The default behavior of [LIKE] is that BLOB operands are cast to TEXT before the comparison is done.
 This compile-time option makes SQLite run more efficiently when processing queries that use the [LIKE] operator, at the expense of breaking backwards compatibility. However, the backwards compatibility break may be only a technicality. There was a long-standing bug in the [LIKE] processing logic (see [https://www.sqlite.org/src/info/05f43be8fdda9f]) that caused it to misbehavior for BLOB operands and nobody observed that bug in nearly 10 years of active use. So for more users, it is probably safe to enable this compile-time option and thereby save a little CPU time on LIKE queries.
 This compile-time option affects the SQL [LIKE] operator only and has no impact on the [sqlite3_strlike()] C-language interface. } COMPILE_OPTION {SQLITE_MAX_MEMORY=N} { This option limits the total amount of memory that SQLite will request from malloc() to N bytes. Any attempt by SQLite to allocate new memory that would cause the sum of all allocations held by SQLite to exceed N bytes will result in an out-of-memory error. This is a hard upper limit. See also the [sqlite3_soft_heap_limit()] interface.
 This limit is only functional if memory usage statistics are available via the [sqlite3_memory_used()] and [sqlite3_status64]([SQLITE_STATUS_MEMORY_USED]) interfaces. Without that memory usage information, SQLite has no way of knowing when it is about to go over the limit, and thus is unable to prevent the excess memory allocation. Memory usage tracking is turned on by default, but can be disabled at compile-time using the [SQLITE_DEFAULT_MEMSTATUS] option, or at start-time using [sqlite3_config]([SQLITE_CONFIG_MEMSTATUS]). } COMPILE_OPTION {SQLITE_MAX_MMAP_SIZE=N} { This macro sets a hard upper bound on the amount of address space that can be used by any single database for memory-mapped I/O. Setting this value to 0 completely disables memory-mapped I/O and causes logic associated with memory-mapped I/O to be omitted from the build. This option does change the default memory-mapped I/O address space size (set by [SQLITE_DEFAULT_MMAP_SIZE] or sqlite3_config([SQLITE_CONFIG_MMAP_SIZE]) or the run-time memory-mapped I/O address space size (set by sqlite3_file_control([SQLITE_FCNTL_MMAP_SIZE]) or [PRAGMA mmap_size]) as long as those other settings are less than the maximum value defined here. } COMPILE_OPTION {SQLITE_MAX_SCHEMA_RETRY=N} { Whenever the database schema changes, prepared statements are automatically reprepared to accommodate the new schema. There is a race condition here in that if one thread is constantly changing the schema, another thread might spin on reparses and repreparations of a prepared statement and never get any real work done. This parameter prevents an infinite loop by forcing the spinning thread to give up after a fixed number of attempts at recompiling the prepared statement. The default setting is 50 which is more than adequate for most applications. } COMPILE_OPTION {SQLITE_MAX_WORKER_THREADS=N} { Set an upper bound on the [sqlite3_limit](db,[SQLITE_LIMIT_WORKER_THREADS],N) setting that determines the maximum number of auxiliary threads that a single [prepared statement] will use to aid with CPU-intensive computations (mostly sorting). See also the [SQLITE_DEFAULT_WORKER_THREADS] options. } COMPILE_OPTION {SQLITE_MINIMUM_FILE_DESCRIPTOR=N} { The unix [VFS] will never use a file descriptor less than N. The default value of N is 3.
 Avoiding the use of low-numbered file descriptors is a defense against accidental database corruption. If a database file was opened using file descriptor 2, for example, and then an assert() failed and invoked write(2,...), that would likely cause database corruption by overwriting part of the database file with the assertion error message. Using only higher-valued file descriptors avoids this potential problem. The protection against using low-numbered file descriptors can be disabled by setting this compile-time option to 0. } COMPILE_OPTION {SQLITE_POWERSAFE_OVERWRITE=<0 or 1>} { This option changes the default assumption about [powersafe overwrite] for the underlying filesystems for the unix and windows [VFSes]. Setting SQLITE_POWERSAFE_OVERWRITE to 1 causes SQLite to assume that application-level writes cannot changes bytes outside the range of bytes written even if the write occurs just before a power loss. With SQLITE_POWERSAFE_OVERWRITE set to 0, SQLite assumes that other bytes in the same sector with a written byte might be changed or damaged by a power loss. } COMPILE_OPTION {SQLITE_REVERSE_UNORDERED_SELECTS} { This option causes the [PRAGMA reverse_unordered_selects] setting to be enabled by default. When enabled, [SELECT] statements that lack an ORDER BY clause will run in reverse order.
 This option is useful for detecting when applications (incorrectly) assume that the order of rows in a SELECT without an ORDER BY clause will always be the same. } COMPILE_OPTION {SQLITE_SORTER_PMASZ=N} { If multi-threaded processing is enabled via the [PRAGMA threads] setting, then sort operations will attempt to start helper threads when the amount of content to be sorted exceeds the minimum of the [cache_size] and PMA Size determined by the [SQLITE_CONFIG_PMASZ] start-time option. This compile-time option sets the default value for the [SQLITE_CONFIG_PMASZ] start-time option. The default value is 250. } COMPILE_OPTION {SQLITE_STMTJRNL_SPILL=N} { The SQLITE_STMTJRNL_SPILL compile-time option determines the default setting of the [SQLITE_CONFIG_STMTJRNL_SPILL] start-time setting. That setting determines the size threshold above which [statement journals] are moved from memory to disk. } COMPILE_OPTION {SQLITE_WIN32_MALLOC} { This option enables the use of the Windows Heap API functions for memory allocation instead of the standard library malloc() and free() routines. } COMPILE_OPTION {YYSTACKDEPTH=<max_depth>} { This macro sets the maximum depth of the LALR(1) stack used by the SQL parser within SQLite. The default value is 100. A typical application will use less than about 20 levels of the stack. Developers whose applications contain SQL statements that need more than 100 LALR(1) stack entries should seriously consider refactoring their SQL as it is likely to be well beyond the ability of any human to comprehend. } </tcl>
 Options To Set Size Limits

There are compile-time options that will set upper bounds on the sizes of various structures in SQLite. The compile-time options normally set a hard upper bound that can be changed at run-time on individual [database connections] using the [sqlite3_limit()] interface.

The compile-time options for setting upper bounds are [limits | documented separately]. The following is a list of the available settings:

 [SQLITE_MAX_ATTACHED]

 [SQLITE_MAX_COLUMN]

 [SQLITE_MAX_COMPOUND_SELECT]

 [SQLITE_MAX_EXPR_DEPTH]

 [SQLITE_MAX_FUNCTION_ARG]

 [SQLITE_MAX_LENGTH]

 [SQLITE_MAX_LIKE_PATTERN_LENGTH]

 [SQLITE_MAX_PAGE_COUNT]

 [SQLITE_MAX_SQL_LENGTH]

 [SQLITE_MAX_VARIABLE_NUMBER]

 Options To Control Operating Characteristics
 <tcl> COMPILE_OPTION {SQLITE_4_BYTE_ALIGNED_MALLOC} { On most systems, the malloc() system call returns a buffer that is aligned to an 8-byte boundary. But on some systems (ex: windows) malloc() returns 4-byte aligned pointer. This compile-time option must be used on systems that return 4-byte aligned pointers from malloc(). } COMPILE_OPTION {SQLITE_CASE_SENSITIVE_LIKE} { If this option is present, then the built-in [LIKE] operator will be case sensitive. This same effect can be achieved at run-time using the [case_sensitive_like pragma]. } COMPILE_OPTION {SQLITE_DIRECT_OVERFLOW_READ} { When this option is present, content contained in [overflow pages] of the database file is read directly from disk, bypassing the [page cache], during read transactions. In applications that do a lot of reads of large BLOBs, this option might improve read performance. } COMPILE_OPTION {SQLITE_HAVE_ISNAN} { If this option is present, then SQLite will use the isnan() function from the system math library. This is an alias for the [HAVE_ISNAN] configuration option. } COMPILE_OPTION {SQLITE_OS_OTHER=<0 or 1>} { The option causes SQLite to omit its built-in operating system interfaces for Unix, Windows, and OS/2. The resulting library will have no default [sqlite3_vfs | operating system interface]. Applications must use [sqlite3_vfs_register()] to register an appropriate interface before using SQLite. Applications must also supply implementations for the [sqlite3_os_init()] and [sqlite3_os_end()] interfaces. The usual practice is for the supplied [sqlite3_os_init()] to invoke [sqlite3_vfs_register()]. SQLite will automatically invoke [sqlite3_os_init()] when it initializes. This option is typically used when building SQLite for an embedded platform with a custom operating system. } COMPILE_OPTION {SQLITE_SECURE_DELETE} { This compile-time option changes the default setting of the [secure_delete pragma]. When this option is not used, secure_delete defaults to off. When this option is present, secure_delete defaults to on. The secure_delete setting causes deleted content to be overwritten with zeros. There is a small performance penalty since additional I/O must occur. On the other hand, secure_delete can prevent fragments of sensitive information from lingering in unused parts of the database file after it has been deleted. See the documentation on the [secure_delete pragma] for additional information. } COMPILE_OPTION {SQLITE_THREADSAFE=<0 or 1 or 2>} { This option controls whether or not code is included in SQLite to enable it to operate safely in a multithreaded environment. The default is SQLITE_THREADSAFE=1 which is safe for use in a multithreaded environment. When compiled with SQLITE_THREADSAFE=0 all mutexing code is omitted and it is unsafe to use SQLite in a multithreaded program. When compiled with SQLITE_THREADSAFE=2, SQLite can be used in a multithreaded program so long as no two threads attempt to use the same [database connection] (or any [prepared statements] derived from that database connection) at the same time. To put it another way, SQLITE_THREADSAFE=1 sets the default [threading mode] to Serialized. SQLITE_THREADSAFE=2 sets the default [threading mode] to Multi-threaded. And SQLITE_THREADSAFE=0 sets the [threading mode] to Single-threaded. The value of SQLITE_THREADSAFE can be determined at run-time using the [sqlite3_threadsafe()] interface. When SQLite has been compiled with SQLITE_THREADSAFE=1 or SQLITE_THREADSAFE=2 then the [threading mode] can be altered at run-time using the [sqlite3_config()] interface together with one of these verbs:

[SQLITE_CONFIG_SINGLETHREAD]
[SQLITE_CONFIG_MULTITHREAD]
[SQLITE_CONFIG_SERIALIZED]
 The [SQLITE_OPEN_NOMUTEX] and [SQLITE_OPEN_FULLMUTEX] flags to [sqlite3_open_v2()] can also be used to adjust the [threading mode] of individual [database connections] at run-time. Note that when SQLite is compiled with SQLITE_THREADSAFE=0, the code to make SQLite threadsafe is omitted from the build. When this occurs, it is impossible to change the [threading mode] at start-time or run-time. See the [threading mode] documentation for additional information on aspects of using SQLite in a multithreaded environment. } COMPILE_OPTION {SQLITE_TEMP_STORE=<0 through 3>} { This option controls whether temporary files are stored on disk or in memory. The meanings for various settings of this compile-time option are as follows:

SQLITE_TEMP_STORE	Meaning

0	Always use temporary files

1	Use files by default but allow the [PRAGMA temp_store] command to override

2	Use memory by default but allow the [PRAGMA temp_store] command to override

3	Always use memory

 The default setting is 1. Additional information can be found in [tempstore | tempfiles.html]. } COMPILE_OPTION {SQLITE_TRACE_SIZE_LIMIT=N} { If this macro is defined to a positive integer N, then the length of strings and BLOB that are expanded into parameters in the output of [sqlite3_trace()] is limited to N bytes. } COMPILE_OPTION {SQLITE_USE_URI} { This option causes the [URI filename] process logic to be enabled by default. } </tcl>
 Options To Enable Features Normally Turned Off
 <tcl> COMPILE_OPTION {SQLITE_ALLOW_URI_AUTHORITY} { [URI filenames] normally throws an error if the authority section is not either empty or "localhost". However, if SQLite is compiled with the SQLITE_ALLOW_URI_AUTHORITY compile-time option, then the URI is converted into a Uniform Naming Convention (UNC) filename and passed down to the underlying operating system that way.
 Some future versions of SQLite may change to enable this feature by default. } COMPILE_OPTION {SQLITE_ALLOW_COVERING_INDEX_SCAN=<0 or 1>} { This C-preprocess macro determines the default setting of the [SQLITE_CONFIG_COVERING_INDEX_SCAN] configuration setting. It defaults to 1 (on) which means that covering indices are used for full table scans where possible, in order to reduce I/O and improve performance. However, the use of a covering index for a full scan will cause results to appear in a different order from legacy, which could cause some (incorrectly-coded) legacy applications to break. Hence, the covering index scan option can be disabled at compile-time on systems that what to minimize their risk of exposing errors in legacy applications. } COMPILE_OPTION {SQLITE_ENABLE_8_3_NAMES=<1 or 2>} { If this C-preprocessor macro is defined, then extra code is included that allows SQLite to function on a filesystem that only support 8+3 filenames. If the value of this macro is 1, then the default behavior is to continue to use long filenames and to only use 8+3 filenames if the database connection is opened using [URI filenames] with the "<tt>8_3_names=1</tt>" query parameter. If the value of this macro is 2, then the use of 8+3 filenames becomes the default but may be disabled on using the <tt>8_3_names=0</tt> query parameter. } COMPILE_OPTION {SQLITE_ENABLE_API_ARMOR} { When defined, this C-preprocessor macro activates extra code that attempts to detect misuse of the SQLite API, such as passing in NULL pointers to required parameters or using objects after they have been destroyed. } COMPILE_OPTION {SQLITE_ENABLE_ATOMIC_WRITE} { If this C-preprocessor macro is defined and if the xDeviceCharacteristics method of [sqlite3_io_methods] object for a database file reports (via one of the [SQLITE_IOCAP_ATOMIC] bits) that the filesystem supports atomic writes and if a transaction involves a change to only a single page of the database file, then the transaction commits with just a single write request of a single page of the database and no rollback journal is created or written. On filesystems that support atomic writes, this optimization can result in significant speed improvements for small updates. However, few filesystems support this capability and the code paths that check for this capability slow down write performance on systems that lack atomic write capability, so this feature is disabled by default. } COMPILE_OPTION {SQLITE_ENABLE_BATCH_ATOMIC_WRITE} { This compile-time option enables SQLite to take advantage batch atomic write capabilities in the underlying filesystem. As of SQLite version 3.21.0 ([dateof:3.21.0]) this is only supported on [https://en.wikipedia.org/wiki/F2FS|F2FS]. However, the interface is implemented generically, using [sqlite3_file_control()] with [SQLITE_FCNTL_BEGIN_ATOMIC_WRITE] and [SQLITE_FCNTL_COMMIT_ATOMIC_WRITE] so the capability can be added to other filesystem times in the future. When this option is enabled, SQLite automatically detects that the underlying filesystem supports batch atomic writes, and when it does so it avoids writing the [rollback journal] for transaction control. This can make transactions over twice as fast, while simultaneously reducing wear on SSD storage devices.
 Future versions of SQLite might enable the batch-atomic-write capability by default, at which point this compile-time option will become superfluous. } COMPILE_OPTION {SQLITE_ENABLE_COLUMN_METADATA} { When this C-preprocessor macro is defined, SQLite includes some additional APIs that provide convenient access to meta-data about tables and queries. The APIs that are enabled by this option are:

 [sqlite3_column_database_name()]

 [sqlite3_column_database_name16()]

 [sqlite3_column_table_name()]

 [sqlite3_column_table_name16()]

 [sqlite3_column_origin_name()]

 [sqlite3_column_origin_name16()]

 } COMPILE_OPTION {SQLITE_ENABLE_DBPAGE_VTAB} { This option enables the [https://sqlite.org/src/file/src/dbpage.c|sqlite_dbpage virtual table]. } COMPILE_OPTION {SQLITE_ENABLE_DBSTAT_VTAB} { This option enables the [dbstat virtual table]. } COMPILE_OPTION {SQLITE_ENABLE_DESERIALIZE} { This option enables the [sqlite3_serialize()] and [sqlite3_deserialize()] interfaces.
 Future releases of SQLite might enable those interfaces by default and instead offer an SQLITE_OMIT_DESERIALIZE option to leave them out. } COMPILE_OPTION {SQLITE_ENABLE_EXPLAIN_COMMENTS} { This option adds extra logic to SQLite that inserts comment text into the output of [EXPLAIN]. These extra comments use extra memory, thus making [prepared statements] larger and very slightly slower, and so they are turned off by default and in most application. But some applications, such as the [command-line shell] for SQLite, value clarity of EXPLAIN output over raw performance and so this compile-time option is available to them. The SQLITE_ENABLE_EXPLAIN_COMMENTS compile-time option is also enabled automatically if [SQLITE_DEBUG] is enabled. } COMPILE_OPTION {SQLITE_ENABLE_FTS3} { When this option is defined in the [amalgamation], version 3 of the full-text search engine is added to the build automatically. } COMPILE_OPTION {SQLITE_ENABLE_FTS3_PARENTHESIS} { This option modifies the query pattern parser in FTS3 such that it supports operators AND and NOT (in addition to the usual OR and NEAR) and also allows query expressions to contain nested parenthesis. } COMPILE_OPTION {SQLITE_ENABLE_FTS3_TOKENIZER} { This option enables the two-argument version of the [fts3_tokenizer()] interface. The second argument to fts3_tokenizer() is suppose to be a pointer to a function (encoded as a BLOB) that implements an application defined tokenizer. If hostile actors are able to run the two-argument version of fts3_tokenizer() with an arbitrary second argument, they could use crash or take control of the process.
 Because of security concerns, the two-argument fts3_tokenizer() feature was disabled beginning with [Version 3.11.0] ([dateof:3.11.0]) unless this compile-time option is used. [Version 3.12.0] ([dateof:3.12.0]) added the [sqlite3_db_config](db,[SQLITE_DBCONFIG_ENABLE_FTS3_TOKENIZER],1,0) interface that activates the two-argument version of [fts3_tokenizer()] for a specific [database connection] at run-time. } COMPILE_OPTION {SQLITE_ENABLE_FTS4} { When this option is defined in the [amalgamation], versions 3 and 4 of the full-text search engine is added to the build automatically. } COMPILE_OPTION {SQLITE_ENABLE_FTS5} { When this option is defined in the [amalgamation], versions 5 of the full-text search engine ([fts5]) is added to the build automatically. } COMPILE_OPTION {SQLITE_ENABLE_ICU} { This option causes the [http://www.icu-project.org/ | International Components for Unicode] or "ICU" extension to SQLite to be added to the build. } COMPILE_OPTION {SQLITE_ENABLE_IOTRACE} { When both the SQLite core and the [Command Line Interface] (CLI) are both compiled with this option, then the CLI provides an extra command named ".iotrace" that provides a low-level log of I/O activity. This option is experimental and may be discontinued in a future release. } COMPILE_OPTION {SQLITE_ENABLE_JSON1} { When this option is defined in the [amalgamation], the [JSON SQL functions] are added to the build automatically. } COMPILE_OPTION {SQLITE_ENABLE_LOCKING_STYLE} { This option enables additional logic in the OS interface layer for Mac OS X. The additional logic attempts to determine the type of the underlying filesystem and choose and alternative locking strategy that works correctly for that filesystem type. Five locking strategies are available:

 POSIX locking style. This is the default locking style and the style used by other (non Mac OS X) Unixes. Locks are obtained and released using the fcntl() system call.
 AFP locking style. This locking style is used for network file systems that use the AFP (Apple Filing Protocol) protocol. Locks are obtained by calling the library function _AFPFSSetLock().
 Flock locking style. This is used for file-systems that do not support POSIX locking style. Locks are obtained and released using the flock() system call.
 Dot-file locking style. This locking style is used when neither flock nor POSIX locking styles are supported by the file system. Database locks are obtained by creating and entry in the file-system at a well-known location relative to the database file (a "dot-file") and relinquished by deleting the same file.
 No locking style. If none of the above can be supported, this locking style is used. No database locking mechanism is used. When this system is used it is not safe for a single database to be accessed by multiple clients.
 Additionally, five extra [VFS] implementations are provided as well as the default. By specifying one of the extra VFS implementations when calling [sqlite3_open_v2()], an application may bypass the file-system detection logic and explicitly select one of the above locking styles. The five extra [VFS] implementations are called "unix-posix", "unix-afp", "unix-flock", "unix-dotfile" and "unix-none". } COMPILE_OPTION {SQLITE_ENABLE_MEMORY_MANAGEMENT} { This option adds extra logic to SQLite that allows it to release unused memory upon request. This option must be enabled in order for the [sqlite3_release_memory()] interface to work. If this compile-time option is not used, the [sqlite3_release_memory()] interface is a no-op. } COMPILE_OPTION {SQLITE_ENABLE_MEMSYS3} { This option includes code in SQLite that implements an alternative memory allocator. This alternative memory allocator is only engaged when the [SQLITE_CONFIG_HEAP] option to [sqlite3_config()] is used to supply a large chunk of memory from which all memory allocations are taken. The MEMSYS3 memory allocator uses a hybrid allocation algorithm patterned after dlmalloc(). Only one of SQLITE_ENABLE_MEMSYS3 and SQLITE_ENABLE_MEMSYS5 may be enabled at once. } COMPILE_OPTION {SQLITE_ENABLE_MEMSYS5} { This option includes code in SQLite that implements an alternative memory allocator. This alternative memory allocator is only engaged when the [SQLITE_CONFIG_HEAP] option to [sqlite3_config()] is used to supply a large chunk of memory from which all memory allocations are taken. The MEMSYS5 module rounds all allocations up to the next power of two and uses a first-fit, buddy-allocator algorithm that provides strong guarantees against fragmentation and breakdown subject to certain operating constraints. } COMPILE_OPTION {SQLITE_ENABLE_NULL_TRIM} { This option enables an optimization that omits NULL columns at the ends of rows, for a space savings on disk.
 Databases generated with this option enabled are not readable by SQLite version 3.1.6 ([dateof:3.1.6]) and earlier. Also, databases generated with this option enabled are prone to triggering the [https://www.sqlite.org/src/info/e6e962d6b0f06f46e|e6e962d6b0f06f46] bug in the [sqlite3_blob_reopen()] interface. For those reasons, this optimization is disabled by default. However, this optimization may be enabled by default in a future release of SQLite. } COMPILE_OPTION {SQLITE_ENABLE_OFFSET_SQL_FUNC} { This option enables support for the [sqlite_offset(X)] SQL function.
 The [sqlite_offset(X)] SQL function requires a new interface on the B-tree storage engine, a new opcode in the [virtual machine] that runs SQL statements, and a new conditional in a critical path of the code generator. To avoid that overhead in applications that do not need the utility of sqlite_offset(X), the function is disabled by default. } COMPILE_OPTION {SQLITE_ENABLE_PREUPDATE_HOOK} { This option enables [sqlite3_preupdate_hook|several new APIs] that provide callbacks prior to any change to a [rowid table]. The callbacks can be used to record the state of the row before the change occurs.
The action of the preupdate hook is similar to the [sqlite3_update_hook|update hook] except that the callback is invoked before the change, not afterwards, and the preupdate hook interfaces are omitted unless this compile-time option is used.
The preupdate hook interfaces were originally added to support the [session] extension. } COMPILE_OPTION {SQLITE_ENABLE_QPSG} { This option causes the [query planner stability guarantee] (QPSG) to be on by default. Normally the QPSG is off and must be activated at run-time using the [SQLITE_DBCONFIG_ENABLE_QPSG] option to the [sqlite3_db_config()] interface. } COMPILE_OPTION {SQLITE_ENABLE_RBU} { Enable the code the implements the [RBU extension]. } COMPILE_OPTION {SQLITE_ENABLE_RTREE} { This option causes SQLite to include support for the [rtree | R*Tree index extension]. } COMPILE_OPTION {SQLITE_ENABLE_SESSION} { This option enables the [session extension]. } COMPILE_OPTION {SQLITE_ENABLE_STMT_SCANSTATUS} { This option enables the [sqlite3_stmt_scanstatus()] interface. The [sqlite3_stmt_scanstatus()] interface is normally omitted from the build because it imposes a small performance penalty, even on statements that do not use the feature. } COMPILE_OPTION {SQLITE_ENABLE_STMTVTAB} { This compile-time option enables the [SQLITE_STMT virtual table] logic. } COMPILE_OPTION {SQLITE_RTREE_INT_ONLY} { This compile-time option is deprecated and untested. } COMPILE_OPTION {SQLITE_ENABLE_SQLLOG} { This option enables extra code (especially the [SQLITE_CONFIG_SQLLOG] option to [sqlite3_config()]) that can be used to create logs of all SQLite processing performed by an application. These logs can be useful in doing off-line analysis of the behavior of an application, and especially for performance analysis. In order for the SQLITE_ENABLE_SQLLOG option to be useful, some extra code is required. The "test_sqllog.c" source code file in the SQLite source tree is a working example of the required extra code. On unix and windows systems, a developer can append the text of the "test_sqllog.c" source code file to the end of an "sqlite3.c" amalgamation, recompile the application using the -DSQLITE_ENABLE_SQLLOG option, then control logging using environment variables. See the header comment on the "test_sqllog.c" source file for additional detail. } COMPILE_OPTION {SQLITE_ENABLE_STAT2} { This option used to cause the [ANALYZE] command to collect index histogram data in the sqlite_stat2 table. But that functionality was superceded by [SQLITE_ENABLE_STAT3] as of SQLite [version 3.7.9] ([dateof:3.7.9]). The SQLITE_ENABLE_STAT2 compile-time option is now a no-op. } COMPILE_OPTION {SQLITE_ENABLE_STAT3} { This option adds additional logic to the [ANALYZE] command and to the [query planner] that can help SQLite to chose a better query plan under certain situations. The [ANALYZE] command is enhanced to collect histogram data from the left-most column of each index and store that data in the [sqlite_stat3] table. The query planner will then use the histogram data to help it make better index choices. Note, however, that the use of histogram data in query planner violates the [query planner stability guarantee] which is important to some applications.
 } COMPILE_OPTION {SQLITE_ENABLE_STAT4} { This option adds additional logic to the [ANALYZE] command and to the [query planner] that can help SQLite to chose a better query plan under certain situations. The [ANALYZE] command is enhanced to collect histogram data from all columns of every index and store that data in the [sqlite_stat4] table. The query planner will then use the histogram data to help it make better index choices. The downside of this compile-time option is that it violates the [query planner stability guarantee] making it more difficult to ensure consistent performance in mass-produced applications.
 SQLITE_ENABLE_STAT4 is an enhancement of [SQLITE_ENABLE_STAT3]. STAT3 only recorded histogram data for the left-most column of each index whereas the STAT4 enhancement records histogram data from all columns of each index. The [SQLITE_ENABLE_STAT3] compile-time option is a no-op and is ignored if the SQLITE_ENABLE_STAT4 compile-time option is used. } COMPILE_OPTION {SQLITE_ENABLE_TREE_EXPLAIN} { This compile-time option is no longer used. } COMPILE_OPTION {SQLITE_ENABLE_UPDATE_DELETE_LIMIT} { This option enables an optional ORDER BY and LIMIT clause on [UPDATE] and [DELETE] statements.
If this option is defined, then it must also be defined when using the [Lemon parser generator] tool to generate a parse.c file. Because of this, this option may only be used when the library is built from source, not from the [amalgamation] or from the collection of pre-packaged C files provided for non-Unix like platforms on the website.
 } COMPILE_OPTION {SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION} { When the SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION compile-time option is activated, SQLite will suppress "unknown function" errors when running an [EXPLAIN] or [EXPLAIN QUERY PLAN]. Instead of throwing an error, SQLite will insert a substitute no-op function named "unknown()". The substitution of "unknown()" in place of unrecognized functions only occurs on [EXPLAIN] and [EXPLAIN QUERY PLAN], not on ordinary statements.
 When used in the [command-line shell], the SQLITE_ENABLE_UNKNOWN_SQL_FUNCTION feature allows SQL text that contains application-defined functions to be pasted into the shell for analysis and debugging without having to create and load an extension that implements the application-defined functions. } COMPILE_OPTION {SQLITE_ENABLE_UNLOCK_NOTIFY} { This option enables the [sqlite3_unlock_notify()] interface and its associated functionality. See the documentation titled [Using the SQLite Unlock Notification Feature] for additional information. } COMPILE_OPTION {SQLITE_INTROSPECTION_PRAGMAS} { This option adds some extra PRAGMA statements such as [PRAGMA function_list], [PRAGMA module_list], and [PRAGMA pragma_list]. } COMPILE_OPTION {SQLITE_SOUNDEX} { This option enables the [soundex() SQL function]. } COMPILE_OPTION {SQLITE_USE_ALLOCA} { If this option is enabled, then the alloca() memory allocator will be used in a few situations where it is appropriate. This results in a slightly smaller and faster binary. The SQLITE_USE_ALLOCA compile-time only only works, of course, on systems that support alloca(). } COMPILE_OPTION {SQLITE_USE_FCNTL_TRACE} { This option causes SQLite to issue extra [SQLITE_FCNTL_TRACE] file controls to provide supplementary information to the VFS. The "vfslog.c" extension makes use of this to provide enhanced logs of VFS activity. } COMPILE_OPTION {SQLITE_USE_ZLIB} { This option causes some extensions to link against the [https://zlib.net|zlib compression library].
 This option has no affect on the SQLite core. It is only used by extensions. This is option is necessary for the commpression and decompression functions that are part of [SQL Archive] support in the [command-line shell].
 When compiling with this option, it will normally be necessary to add a linker option to include the zlib library in the build. Normal this option is "-lz" but might be different on different systems.
 When building with MSVC on Windows systems, one can put the zlib source code in the compat/zlib subdirectory of the source tree and then add the USE_ZLIB=1 option to the nmake command to cause the The Makefile.msc to automatically build and use an appropriate zlib library implementation. } COMPILE_OPTION {YYTRACKMAXSTACKDEPTH} { This option causes the LALR(1) parser stack depth to be tracked and reported using the [sqlite3_status]([SQLITE_STATUS_PARSER_STACK],...) interface. SQLite's LALR(1) parser has a fixed stack depth (determined at compile-time using the [YYSTACKDEPTH] options). This option can be used to help determine if an application is getting close to exceeding the maximum LALR(1) stack depth. } </tcl>
 Options To Disable Features Normally Turned On
 <tcl> COMPILE_OPTION {SQLITE_DISABLE_LFS} { If this C-preprocessor macro is defined, large file support is disabled. } COMPILE_OPTION {SQLITE_DISABLE_DIRSYNC} { If this C-preprocessor macro is defined, directory syncs are disabled. SQLite typically attempts to sync the parent directory when a file is deleted to ensure the directory entries are updated immediately on disk. } COMPILE_OPTION {SQLITE_DISABLE_FTS3_UNICODE} { If this C-preprocessor macro is defined, the [unicode61] tokenizer in [FTS3] is omitted from the build and is unavailable to applications. } COMPILE_OPTION {SQLITE_DISABLE_FTS4_DEFERRED} { If this C-preprocessor macro disables the "deferred token" optimization in [FTS4]. The "deferred token" optimization avoids loading massive posting lists for terms that are in most documents of the collection and instead simply scans for those tokens in the document source. [FTS4] should get exactly the same answer both with and without this optimization. } COMPILE_OPTION {SQLITE_DISABLE_INTRINSIC} { This option disables the use of compiler-specific built-in functions such as __builtin_bswap32() and __builtin_add_overflow() in GCC and Clang, or _byteswap_ulong() and _ReadWriteBarrier() with MSVC. } </tcl> <tcl> hd_fragment "omitfeatures" hd_keywords "omitfeatures" </tcl>
 Options To Omit Features

The following options can be used to [relfootprint | reduce the size of the compiled library] by omitting unused features. This is probably only useful in embedded systems where space is especially tight, as even with all features included the SQLite library is relatively small. Don't forget to tell your compiler to optimize for binary size! (the -Os option if using GCC). Telling your compiler to optimize for size usually has a much larger impact on library footprint than employing any of these compile-time options. You should also verify that debugging options are disabled.

The macros in this section do not require values. The following compilation switches all have the same effect:
 -DSQLITE_OMIT_ALTERTABLE
 -DSQLITE_OMIT_ALTERTABLE=1
 -DSQLITE_OMIT_ALTERTABLE=0

If any of these options are defined, then the same set of SQLITE_OMIT_* options must also be defined when using the [Lemon parser generator] tool to generate the parse.c file and when compiling the 'mkkeywordhash' tool which generates the keywordhash.h file. Because of this, these options may only be used when the library is built from canonical source, not from the [amalgamation]. Some SQLITE_OMIT_* options might work, or appear to work, when used with the [amalgamation]. But this is not guaranteed. In general, always compile from canonical sources in order to take advantage of SQLITE_OMIT_* options.

 Important Note: The SQLITE_OMIT_* options may not work with the [amalgamation]. SQLITE_OMIT_* compile-time options usually work correctly only when SQLite is built from canonical source files.

Special versions of the SQLite amalgamation that do work with a predetermined set of SQLITE_OMIT_* options can be generated. To do so, make a copy of the Makefile.linux-gcc makefile template in the canonical source code distribution. Change the name of your copy to simply "Makefile". Then edit "Makefile" to set up appropriate compile-time options. Then type: <codeblock> make clean; make sqlite3.c </codeblock>
The resulting "sqlite3.c" amalgamation code file (and its associated header file "sqlite3.h") can then be moved to a non-unix platform for final compilation using a native compiler.

The SQLITE_OMIT_* options are unsupported. By this we mean that an SQLITE_OMIT_* option that omits code from the build in the current release might become a no-op in the next release. Or the other way around: an SQLITE_OMIT_* that is a no-op in the current release might cause code to be excluded in the next release. Also, not all SQLITE_OMIT_* options are tested. Some SQLITE_OMIT_* options might cause SQLite to malfunction and/or provide incorrect answers.
 Important Note: The SQLITE_OMIT_* compile-time options are mostly unsupported.

The following are the available OMIT options: <tcl> COMPILE_OPTION {SQLITE_OMIT_ALTERTABLE} { When this option is defined, the [ALTER TABLE] command is not included in the library. Executing an [ALTER TABLE] statement causes a parse error. } COMPILE_OPTION {SQLITE_OMIT_ANALYZE} { When this option is defined, the [ANALYZE] command is omitted from the build. } COMPILE_OPTION {SQLITE_OMIT_ATTACH} { When this option is defined, the [ATTACH] and [DETACH] commands are omitted from the build. } COMPILE_OPTION {SQLITE_OMIT_AUTHORIZATION} { Defining this option omits the authorization callback feature from the library. The [sqlite3_set_authorizer()] API function is not present in the library. } COMPILE_OPTION {SQLITE_OMIT_AUTOINCREMENT} { This option is omits the [AUTOINCREMENT] feature. When this is macro is defined, columns declared as "[INTEGER PRIMARY KEY] AUTOINCREMENT" behave in the same way as columns declared as "[INTEGER PRIMARY KEY]" when a NULL is inserted. The sqlite_sequence system table is neither created, nor respected if it already exists. } COMPILE_OPTION {SQLITE_OMIT_AUTOINIT} { For backwards compatibility with older versions of SQLite that lack the [sqlite3_initialize()] interface, the [sqlite3_initialize()] interface is called automatically upon entry to certain key interfaces such as [sqlite3_open()], [sqlite3_vfs_register()], and [sqlite3_mprintf()]. The overhead of invoking [sqlite3_initialize()] automatically in this way may be omitted by building SQLite with the SQLITE_OMIT_AUTOINIT C-preprocessor macro. When built using SQLITE_OMIT_AUTOINIT, SQLite will not automatically initialize itself and the application is required to invoke [sqlite3_initialize()] directly prior to beginning use of the SQLite library. } COMPILE_OPTION {SQLITE_OMIT_AUTOMATIC_INDEX} { This option is used to omit the [automatic indexing] functionality. See also: [SQLITE_DEFAULT_AUTOMATIC_INDEX]. } COMPILE_OPTION {SQLITE_OMIT_AUTORESET} { By default, the [sqlite3_step()] interface will automatically invoke [sqlite3_reset()] to reset the [prepared statement] if necessary. This compile-time option changes that behavior so that [sqlite3_step()] will return [SQLITE_MISUSE] if it called again after returning anything other than [SQLITE_ROW], [SQLITE_BUSY], or [SQLITE_LOCKED] unless there was an intervening call to [sqlite3_reset()]. In SQLite [version 18.104.22.168] ([dateof:188.8.131.52]) and earlier, [sqlite3_step()] used to always return [SQLITE_MISUSE] if it was invoked again after returning anything other than [SQLITE_ROW] without an intervening call to [sqlite3_reset()]. This caused problems on some poorly written smartphone applications which did not correctly handle the [SQLITE_LOCKED] and [SQLITE_BUSY] error returns. Rather than fix the many defective smartphone applications, the behavior of SQLite was changed in 22.214.171.124 to automatically reset the prepared statement. But that changed caused issues in other improperly implemented applications that were actually looking for an [SQLITE_MISUSE] return to terminate their query loops. (Anytime an application gets an SQLITE_MISUSE error code from SQLite, that means the application is misusing the SQLite interface and is thus incorrectly implemented.) The SQLITE_OMIT_AUTORESET interface was added to SQLite [version 3.7.5] ([dateof:3.7.5]) in an effort to get all of the (broken) applications to work again without having to actually fix the applications. } COMPILE_OPTION {SQLITE_OMIT_AUTOVACUUM} { If this option is defined, the library cannot create or write to databases that support [auto_vacuum]. Executing a [PRAGMA auto_vacuum] statement is not an error (since unknown PRAGMAs are silently ignored), but does not return a value or modify the auto-vacuum flag in the database file. If a database that supports auto-vacuum is opened by a library compiled with this option, it is automatically opened in read-only mode. } COMPILE_OPTION {SQLITE_OMIT_BETWEEN_OPTIMIZATION} { This option disables the use of indices with WHERE clause terms that employ the BETWEEN operator. } COMPILE_OPTION {SQLITE_OMIT_BLOB_LITERAL} { When this option is defined, it is not possible to specify a blob in an SQL statement using the X'ABCD' syntax. } COMPILE_OPTION {SQLITE_OMIT_BTREECOUNT} { When this option is defined, an optimization that accelerates counting all entries in a table (in other words, an optimization that helps "SELECT count(*) FROM table" run faster) is omitted. } COMPILE_OPTION {SQLITE_OMIT_BUILTIN_TEST} { This compile-time option has been renamed to [SQLITE_UNTESTABLE]. } COMPILE_OPTION {SQLITE_OMIT_CAST} { This option causes SQLite to omit support for the CAST operator. } COMPILE_OPTION {SQLITE_OMIT_CHECK} { This option causes SQLite to omit support for CHECK constraints. The parser will still accept CHECK constraints in SQL statements, they will just not be enforced. } COMPILE_OPTION {SQLITE_OMIT_COMPILEOPTION_DIAGS} { This option is used to omit the compile-time option diagnostics available in SQLite, including the [sqlite3_compileoption_used()] and [sqlite3_compileoption_get()] C/C++ functions, the [sqlite_compileoption_used()] and [sqlite_compileoption_get()] SQL functions, and the [compile_options pragma]. } COMPILE_OPTION {SQLITE_OMIT_COMPLETE} { This option causes the [sqlite3_complete()] and [sqlite3_complete16()] interfaces to be omitted. } COMPILE_OPTION {SQLITE_OMIT_COMPOUND_SELECT} { This option is used to omit the compound [SELECT] functionality. [SELECT] statements that use the UNION, UNION ALL, INTERSECT or EXCEPT compound SELECT operators will cause a parse error. An [INSERT] statement with multiple values in the VALUES clause is implemented internally as a compound SELECT. Hence, this option also disables the ability to insert more than a single row using an INSERT INTO ... VALUES ... statement. } COMPILE_OPTION {SQLITE_OMIT_CTE} { This option causes support for [common table expressions] to be omitted. } COMPILE_OPTION {SQLITE_OMIT_DATETIME_FUNCS} { If this option is defined, SQLite's built-in date and time manipulation functions are omitted. Specifically, the SQL functions julianday(), date(), time(), datetime() and strftime() are not available. The default column values CURRENT_TIME, CURRENT_DATE and CURRENT_TIMESTAMP are still available. } COMPILE_OPTION {SQLITE_OMIT_DECLTYPE} { This option causes SQLite to omit support for the [sqlite3_column_decltype()] and [sqlite3_column_decltype16()] interfaces. } COMPILE_OPTION {SQLITE_OMIT_DEPRECATED} { This option causes SQLite to omit support for interfaces marked as deprecated. This includes [sqlite3_aggregate_count()], [sqlite3_expired()], [sqlite3_transfer_bindings()], [sqlite3_global_recover()], [sqlite3_thread_cleanup()] and [sqlite3_memory_alarm()] interfaces. } COMPILE_OPTION {SQLITE_OMIT_DISKIO} { This option omits all support for writing to the disk and forces databases to exist in memory only. This option has not been maintained and probably does not work with newer versions of SQLite. } COMPILE_OPTION {SQLITE_OMIT_EXPLAIN} { Defining this option causes the [EXPLAIN] command to be omitted from the library. Attempting to execute an [EXPLAIN] statement will cause a parse error. } COMPILE_OPTION {SQLITE_OMIT_FLAG_PRAGMAS} { This option omits support for a subset of [PRAGMA] commands that query and set boolean properties. } COMPILE_OPTION {SQLITE_OMIT_FLOATING_POINT} { This option is used to omit floating-point number support from the SQLite library. When specified, specifying a floating point number as a literal (i.e. "1.01") results in a parse error.
In the future, this option may also disable other floating point functionality, for example the [sqlite3_result_double()], [sqlite3_bind_double()], [sqlite3_value_double()] and [sqlite3_column_double()] API functions.
 } COMPILE_OPTION {SQLITE_OMIT_FOREIGN_KEY} { If this option is defined, then [foreign key constraint] syntax is not recognized. } COMPILE_OPTION {SQLITE_OMIT_GET_TABLE} { This option causes support for [sqlite3_get_table()] and [sqlite3_free_table()] to be omitted. } COMPILE_OPTION {SQLITE_OMIT_INCRBLOB} { This option causes support for [sqlite3_blob | incremental BLOB I/O] to be omitted. } COMPILE_OPTION {SQLITE_OMIT_INTEGRITY_CHECK} { This option omits support for the [integrity_check pragma]. } COMPILE_OPTION {SQLITE_OMIT_LIKE_OPTIMIZATION} { This option disables the ability of SQLite to use indices to help resolve [LIKE] and [GLOB] operators in a WHERE clause. } COMPILE_OPTION {SQLITE_OMIT_LOAD_EXTENSION} { This option omits the entire extension loading mechanism from SQLite, including [sqlite3_enable_load_extension()] and [sqlite3_load_extension()] interfaces. } COMPILE_OPTION {SQLITE_OMIT_LOCALTIME} { This option omits the "localtime" modifier from the date and time functions. This option is sometimes useful when trying to compile the date and time functions on a platform that does not support the concept of local time. } COMPILE_OPTION {SQLITE_OMIT_LOOKASIDE} { This option omits the [lookaside memory allocator]. } COMPILE_OPTION {SQLITE_OMIT_MEMORYDB} { When this is defined, the library does not respect the special database name ":memory:" (normally used to create an [in-memory database]). If ":memory:" is passed to [sqlite3_open()], [sqlite3_open16()], or [sqlite3_open_v2()], a file with this name will be opened or created. } COMPILE_OPTION {SQLITE_OMIT_OR_OPTIMIZATION} { This option disables the ability of SQLite to use an index together with terms of a WHERE clause connected by the OR operator. } COMPILE_OPTION {SQLITE_OMIT_PAGER_PRAGMAS} { Defining this option omits pragmas related to the pager subsystem from the build. } COMPILE_OPTION {SQLITE_OMIT_PRAGMA} { This option is used to omit the [PRAGMA] command from the library. Note that it is useful to define the macros that omit specific pragmas in addition to this, as they may also remove supporting code in other sub-systems. This macro removes the [PRAGMA] command only. } COMPILE_OPTION {SQLITE_OMIT_PROGRESS_CALLBACK} { This option may be defined to omit the capability to issue "progress" callbacks during long-running SQL statements. The [sqlite3_progress_handler()] API function is not present in the library. } COMPILE_OPTION {SQLITE_OMIT_QUICKBALANCE} { This option omits an alternative, faster B-Tree balancing routine. Using this option makes SQLite slightly smaller at the expense of making it run slightly slower. } COMPILE_OPTION {SQLITE_OMIT_REINDEX} { When this option is defined, the [REINDEX] command is not included in the library. Executing a [REINDEX] statement causes a parse error. } COMPILE_OPTION {SQLITE_OMIT_SCHEMA_PRAGMAS} { Defining this option omits pragmas for querying the database schema from the build. } COMPILE_OPTION {SQLITE_OMIT_SCHEMA_VERSION_PRAGMAS} { Defining this option omits pragmas for querying and modifying the database schema version and user version from the build. Specifically, the [schema_version] and [user_version] PRAGMAs are omitted. } COMPILE_OPTION {SQLITE_OMIT_SHARED_CACHE} { This option builds SQLite without support for shared-cache mode. The [sqlite3_enable_shared_cache()] is omitted along with a fair amount of logic within the B-Tree subsystem associated with shared cache management. } COMPILE_OPTION {SQLITE_OMIT_SUBQUERY} { If defined, support for sub-selects and the IN() operator are omitted. } COMPILE_OPTION {SQLITE_OMIT_TCL_VARIABLE} { If this macro is defined, then the special "$<variable-name>" syntax used to automatically bind SQL variables to TCL variables is omitted. } COMPILE_OPTION {SQLITE_OMIT_TEMPDB} { This option omits support for TEMP or TEMPORARY tables. } COMPILE_OPTION {SQLITE_OMIT_TRACE} { This option omits support for the [sqlite3_profile()] and [sqlite3_trace()] interfaces and their associated logic. } COMPILE_OPTION {SQLITE_OMIT_TRIGGER} { Defining this option omits support for TRIGGER objects. Neither the [CREATE TRIGGER] or [DROP TRIGGER] commands are available in this case, and attempting to execute either will result in a parse error. This option also disables enforcement of [foreign key constraints], since the code that implements triggers and which is omitted by this option is also used to implement [foreign key actions]. } COMPILE_OPTION {SQLITE_OMIT_TRUNCATE_OPTIMIZATION} { A default build of SQLite, if a [DELETE] statement has no WHERE clause and operates on a table with no triggers, an optimization occurs that causes the DELETE to occur by dropping and recreating the table. Dropping and recreating a table is usually much faster than deleting the table content row by row. This is the "truncate optimization". } COMPILE_OPTION {SQLITE_OMIT_UTF16} { This macro is used to omit support for UTF16 text encoding. When this is defined all API functions that return or accept UTF16 encoded text are unavailable. These functions can be identified by the fact that they end with '16', for example [sqlite3_prepare16()], [sqlite3_column_text16()] and [sqlite3_bind_text16()]. } COMPILE_OPTION {SQLITE_OMIT_VACUUM} { When this option is defined, the [VACUUM] command is not included in the library. Executing a [VACUUM] statement causes a parse error. } COMPILE_OPTION {SQLITE_OMIT_VIEW} { Defining this option omits support for VIEW objects. Neither the [CREATE VIEW] nor the [DROP VIEW] commands are available in this case, and attempting to execute either will result in a parse error. WARNING: If this macro is defined, it will not be possible to open a database for which the schema contains VIEW objects. } COMPILE_OPTION {SQLITE_OMIT_VIRTUALTABLE} { This option omits support for the [sqlite3_vtab | Virtual Table] mechanism in SQLite. } COMPILE_OPTION {SQLITE_OMIT_WAL} { This option omits the "[write-ahead log]" (a.k.a. "[WAL]") capability. } COMPILE_OPTION {SQLITE_OMIT_WSD} { This option builds a version of the SQLite library that contains no Writable Static Data (WSD). WSD is global variables and/or static variables. Some platforms do not support WSD, and this option is necessary in order for SQLite to work those platforms. Unlike other OMIT options which make the SQLite library smaller, this option actually increases the size of SQLite and makes it run a little slower. Only use this option if SQLite is being built for an embedded target that does not support WSD. } COMPILE_OPTION {SQLITE_OMIT_XFER_OPT} { This option omits support for optimizations that help statements of the form "INSERT INTO ... SELECT ..." run faster. } COMPILE_OPTION {SQLITE_UNTESTABLE} { A standard SQLite build includes a small amount of logic associated with [sqlite3_test_control()] to exercise parts of the SQLite core that are otherwise difficult to validate. This compile-time option omits that extra testing logic. This compile-time option was called "SQLITE_OMIT_BUILTIN_TEST" prior to SQLite version 3.16.0 ([dateof:3.16.0]). The name was changed to better describe the implications of using it.
 Setting this compile-time option prevents SQLite from being fully testable. Branch test coverage drops from 100% down to about 95%.
 SQLite developers follow the NASA principle of "fly what you test and test what you fly". This principle is violated if this option is enabled for delivery but disabled for testing. But if this option is enabled during testing, not all branches are reachable. Therefore, the use of this compile-time option is discouraged. } COMPILE_OPTION {SQLITE_ZERO_MALLOC} { This option omits both the [default memory allocator] and the [debugging memory allocator] from the build and substitutes a stub memory allocator that always fails. SQLite will not run with this stub memory allocator since it will be unable to allocate memory. But this stub can be replaced at start-time using [sqlite3_config]([SQLITE_CONFIG_MALLOC],...) or [sqlite3_config]([SQLITE_CONFIG_HEAP],...). So the net effect of this compile-time option is that it allows SQLite to be compiled and linked against a system library that does not support malloc(), free(), and/or realloc(). } </tcl>
 Analysis and Debugging Options
 <tcl> COMPILE_OPTION {SQLITE_DEBUG} { The SQLite source code contains literally thousands of assert() statements used to verify internal assumptions and subroutine preconditions and postconditions. These assert() statements are normally turned off (they generate no code) since turning them on makes SQLite run approximately three times slower. But for testing and analysis, it is useful to turn the assert() statements on. The SQLITE_DEBUG compile-time option does this.
SQLITE_DEBUG also enables some other debugging features, such as special [PRAGMA] statements that turn on tracing and listing features used for troubleshooting and analysis of the [VDBE] and code generator. } COMPILE_OPTION {SQLITE_MEMDEBUG} { The SQLITE_MEMDEBUG option causes an instrumented [debugging memory allocator] to be used as the default memory allocator within SQLite. The instrumented memory allocator checks for misuse of dynamically allocated memory. Examples of misuse include using memory after it is freed, writing off the ends of a memory allocation, freeing memory not previously obtained from the memory allocator, or failing to initialize newly allocated memory. } </tcl>
 Windows-Specific Options
 <tcl> COMPILE_OPTION {SQLITE_WIN32_HEAP_CREATE} { This option forces the Win32 native memory allocator, when enabled, to create a private heap to hold all memory allocations. } COMPILE_OPTION {SQLITE_WIN32_MALLOC_VALIDATE} { This option forces the Win32 native memory allocator, when enabled, to make strategic calls into the HeapValidate() function if assert() is also enabled. } </tcl>
Compiler Linkage Control

The following macros specify interface linkage for certain kinds of SQLite builds. The Makefiles will normally handle setting these macros automatically. Application developers should not need to worry with these macros. The following documentation about these macros is included completeness.
 <tcl> COMPILE_OPTION {SQLITE_API} { This macro identifies a externally visible interface for SQLite. This macro is sometimes set to "extern". But the definition is compiler-specific. } COMPILE_OPTION {SQLITE_APICALL} { This macro identifies the calling convention used by public interface routines in SQLite. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__cdecl" or "__stdcall". The "__cdecl" setting is the default, but "__stdcall" is used when SQLite is intended to be compiled as a Windows system library.
 A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_CALLBACK} { This macro specifies the calling convention used by callback pointers in SQLite. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__cdecl" or "__stdcall". The "__cdecl" setting is the default, but "__stdcall" is used when SQLite is intended to be compiled as a Windows system library.
 A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_CDECL} { This macro specifies the calling convention used by varargs interface routines in SQLite. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__cdecl". This macro is used on varargs routines and so cannot be set to "__stdcall" since the __stdcall calling convention does not support varargs functions.
 A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_SYSCALL} { This macro identifies the calling convention used by operating system interfaces for target the platform for an SQLite build. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__stdcall".
 A single function declaration should contain no more than one of the following: [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } COMPILE_OPTION {SQLITE_TCLAPI} { This macro specifies the calling convention used by the [http://www.tcl.tk | TCL] library interface routines. This macro is not used by the SQLite core, but only by the [TCL Interface] and [TCL test suite]. This macro is normally defined to be nothing, though on Windows builds it can sometimes be set to "__cdecl". This macro is used on TCL library interface routines which are always compiled as __cdecl, even on platforms that prefer to use __stdcall, so this macro should not be set to __stdcall unless the platform as a custom TCL library build that supports __stdcall.
 This macro may not be used in combination with any of [SQLITE_APICALL], [SQLITE_CALLBACK], [SQLITE_CDECL], or [SQLITE_SYSCALL]. } </tcl>


text:
When opening Vienna after upgrade to latest 10.13.4 beta, it crashes right away. At the same time, or just before, Avast Antivirus reacted with message "Infection blocked" with reference to file /Applications/Vienna.app/Contents/Frameworks/libswitchDispatch.dylib
Avast had moved this file to the Chest, so of course Vienna could not start. I put the file back, and then Vienna started normally.
Edit: I have reported this to Avast as a false positive.
Edit 2: Received response from Avast.
Thank you for reporting this.
Our virus specialists have been working on this problem and it has now been fixed. If you're still getting the same detection, please make sure you're using the latest Virus Definitions in Avast.
Vienna crashed, due to Avast
An RSS/Atom newsreader with features comparable to commercial newsreaders.
1 post • Page 1 of 1
- Muffin
- Posts: 29
- Joined: Wed Sep 19, 2012 9:50 am
- Location: France
1 post • Page 1 of 1
Who is online
Users browsing this forum: No registered users

subset: commoncrawl


text:
Common Challenges for Private and Public Cloud Environments
Discover a cloud approach that achieves a high ROI in healthcare
Saint Elizabeth Health Care has been an active participant in the development of community healthcare in Canada for more than a century. Today, Saint Elizabeth has 6,500 employees spread across 25 offices throughout Canada, so they were in need of the newest generation of IT help desk software functionality to respond to rapid organizational growth. Their IT help desk is a 24-7 operation with a very high call volume, staffed with skilled technicians.
The ease of getting up and running on a new IT help desk software application was very important to them because they could not suspend their help desk operation for a traditional "cut over." Essentially, the organization was looking to dramatically cut the time from PO to "go live." As a result, the cloud-based Software-as-a-Service (SaaS) model was very attractive to Saint Elizabeth.
The actual implementation to Giva only required a concentrated effort for about four days of elapsed time. The actual hours spent configuring and customizing Giva was much less than four days as their team had their other responsibilities to attend to during these four days. The team was able to fully customize Giva's SaaS product in only 10 percent of the time that would take to configure/install a similar feature rich on premise solution.
With a cloud approach, Saint Elizabeth does not have to wait years or even months for new product improvements, which is very important to them. Also, with a cloud IT help desk system, there's no need to maintain production and test environments because the new product releases are transparent and seamlessly available. The cloud approach also saves data center space, hardware costs and labor hours. This "green" and sustainable IT approach is an added benefit in Canada in particular, because it is an important part of the country's values and business culture.
Additional Whitepapers
- How Does the Cybersecurity Information Sharing Act (CISA) Impact the Hospital and Healthcare Industry
Patient Safety
- Presentation on Patient Safety: Achieving A New Standard for Care (Institute of Medicine Committee on Data Standards for Patient Safety November, 2003)
- The JCAHO Patient Safety Event - Taxonomy: A Standardised Terminology and Classification Schema for Near Misses and Adverse Events


text:
A 'View' without Barbara Walters after this week
NEW YORK – When Barbara Walters came on the scene, John Kennedy was in the White House, a motorist could fill 'er up for three bucks and no one had heard of the Beatles.
On Friday, capping a spectacular half-century run she began as the so-called "Today" Girl, Walters says goodbye to ABC's "The View."
Behind the scenes she will remain as an executive producer of the New York-based talk show she created 17 years ago, and she'll make ABC News appearances as events warrant and stories catch her eye.
"It's not as if I'm walking into the sunset," cautions Walters, who at 84 looks a decade or two younger as she nurses black coffee in her dressing room amid a tireless pace that, in the same breath, she insists will soon be coming to a halt: "I'm NOT going to be doing a five-day-a-week show, and I'm NOT going after every big 'get.'"
On Thursday's "The View," all 11 past and present co-hosts reunite to honor her as she retires from daily television. Hours after her big farewell on Friday's "View" (seen weekdays at 11 a.m. EDT), "Barbara Walters: Her Story" airs as a two-hour retrospective (9 p.m. EDT).
"Then on May 17," she pledges, "I'm going to be sleeping until noon. May 18, I'm going to sleep until noon."
But what about the day after that? "People ask me, 'How are you gonna feel?' I don't know! It's a new chapter!"
Not just for her. Since the early 1960s, Walter has served as a journalistic throughline for her viewers, an arbiter connecting the dots during five decades of events, newsmakers and stars at NBC's "Today" (from 1961 to 1976), as the first woman co-anchor of ABC's "World News Tonight," on her scores of "big get" specials and a quarter-century co-hosting "20/20."
And she did it after starting out as a "Girl" who crashed the "Mad Man"-esque world of TV news' male dominance.
Asked to speculate on what might land her name in history books, she cites the "many really wonderful young women now on television. If I helped to pave the way, that's more important than if anyone remembers my name.
"And my longevity on the air," she adds as a backup legacy: "That one can work as long as I've worked, and still be vital — it demonstrates there's no age limit for people. And there shouldn't be!"
Walters announced her retirement more than a year ago, and emphasizes it was her choice, motivated because, well, it just seemed time.
"But I feel great," she says. "I'm in perfect health. I've got a lot of energy."
Not that she dismisses broader implications of this looming new passage awaiting her.
"I'm walking away from a career of 38 years, just at ABC News. So I think, 'What's the next milestone?' The next milestone is DEATH!" A wry laugh. "Oh, thanks a LOT!"
But as Walters' career thus far has made clear, she is nothing if not defiant, with a lifetime spent challenging assumptions and naysayers.
Just ask Bill Geddie, who continues as co-executive producer of "The View" with Walters in a partnership born some 25 years ago.
Back then, Geddie, a former "Good Morning America" producer in his early 30s, had grabbed her offer to produce Walters' prime-time specials — and did it, he recalls, against everyone's advice.
"They said, 'She's got two, maybe three more years. Nobody's gonna watch a woman over 60.'" And he laughs.
"I don't think they realized, even by that time, how driven she was, how good she was, how this was not just a job for her, this was her life."
Geddie acknowledges that now, finally, Walters faces a profound change in her storied life.
"But do I think we've seen the last of Barbara Walters? Absolutely not."


text:
That's the message an Italian-American group has for MTV and the cable network's plans to air a reality show that depicts Jersey shore beachgoers as the "hottest, tannest, craziest Guidos."
UNICO National, the largest Italian-American service organization in the country, said Tuesday that "Jersey Shore" relies on crude stereotypes and highlights cursing, bad behavior and violence in depicting renters at a New Jersey beach house.
U.S. & World
Stories that affect your life across the U.S. and around the world.
A MTV promo describes the participants thusly: "They keep their hair high, their muscles juiced and their fists pumping all summer long!"
UNICO President Andre DiMino calls the show "trash television."
The show is scheduled to debut Dec. 3, but there was no immediate comment from MTV.
From the trailer, it looks like the drama will unfold in a house on the shore, where muscle-loving men do pull-ups from the ceiling, couples throw punches and scream like banshees while bikini-wearing babes nap in tanning beds and fret over way-too long nails and hair.
The dialog sounds particularly clever -- "I'm ripped up like Rambo," "I'm hot," and "Don't be a hater" -- with scintillating visuals like a dude with sweaty armpits pumping his fist aggressively in the air.
If you want a sneak peak, watch the video below.


text:
Being from the Austrian Mountains I LOVE skiing. When seeing ski pics in Summer (in Chile) I do sometimes get a little jealous even though summer is nicer anyway.
Today is the first time for me to ski in 2010 and the first time in Colorado. There are no waiting times probably as the prices are so extreme (30.000 CLP)
Since nobody in Chile uses winter tires for their cars every car has to put chains. They rent them for 10.000 CLP and put them on for another 5k CLP.
So skiing for sure is freaking expensive compared to the GDP but also in EUR terms compared to the mother of all ski resorts (Austria)
Here are some pics shot from my mobile. I might edit the post once at home to add more detail.
Me on the chairlift from where I am blogging this:


text:
FamilySearch Wiki:Help wanted on the Wiki
- 1 Volunteers - Help Us Build the Wiki
- 2 Get Started
- 3 Help Wanted by Location
- 4 "How To" Reference Articles
- 5 Even More Opportunities for Beginners
- 6 Get Started
- 7 Wiki Editor Training
- 8 Help
Volunteers - Help Us Build the Wiki[edit | edit source]
Like a barn raising, the Research Wiki can only be built by an involved community. Communities naturally include individuals with different levels of expertise. Share what you know!
Help us by:
- Expanding existing articles
- Creating new articles
- Adding sources
- Linking to other online resources
- Correcting grammar and spelling mistakes
- Combining duplicate articles.
Whatever your level of expertise, the wiki needs you! Come join the wiki barn raising team.
Get Started[edit | edit source]
See the topics below for ideas about how you can help on the wiki. Volunteers should also contact the Moderator for the State, Country and Possessions of interest for suggestions and help for contributions associated for that location.
Do you need help getting started editing? Click here.
General Help Needed On The Wiki[edit | edit source]
In addition to State and Country Projects, the items below involve work that a volunteer can do with minimal training:
- Add information to your county and/or city pages.
- Prepare county histories - county section of each state.
- Repositories - what's in a repository of genealogical interest ... U.S. Canada.
- Outside company providing content ... we are putting in the wiki for formatting.
- Write about Migration Trails - Which Counties and Towns they went through in both the U.S. and Canada.
- Write articles for links that are in red.
- Write articles about little known research methods for various parts of the world.
- Need Moderators to run projects for places around the world
- Join our support team.
- Wiki Projects seeking contributors
- Wiki Cleanup Projects
- Add Categories to articles
In addition to these projects, additional projects that volunteers can easily do are listed below:
- Add each state or county's creation date and parent states/counties. This information can be found using the Place Search in the Family History Library Catalog.
- Add links to digitized state and county histories. A large collection of such histories is Brigham Young University's Family History Archives. A shortcut to searching it for local histories is on the BYU-FHL Digital Books Collection page.
- The Research Wiki is also available in ten other languages. You can help by translating pages into one of the other languages.
Help Wanted by Location[edit | edit source]
Help Wanted - United States[edit | edit source]
Want to help on a specific U.S. State? Click on a state on the map below to go to its Help Wanted Article. State Moderators have a variety tasks needing your assistance.
Help Wanted - Worldwide[edit | edit source]
Regions[edit | edit source]
"How To" Reference Articles[edit | edit source]
Even More Opportunities for Beginners[edit | edit source]
Start Simple[edit | edit source]
- See the Volunteer Opportunities list below
(the listing can be sorted by "ease" of activity)
- Stubs
- Short Pages
- Find pages that could use some TLC, such as Stubs, or Short Pages. There might be a section in these articles that you could enhance by adding content, or spell-checking.
- Are you interested in a specific area? Could you add research tips to pages in that area that are in a specific section of the article, such as cemeteries?
- Another possibility would be to watch genealogy blogs for press or news releases that could be added to the Wiki, if they are not time sensitive.
- Could you check for broken links or add categories to pages?
US County pages[edit | edit source]
Is there something specific that is missing from several of them?
- Examples:
- Suppose several County pages are missing information about local libraries. Could you use an internet site, such as PublicLibraries.com to locate the libraries for each county and add the link to the page?
- Add links to the Family History Center pages, if they are missing.
- Looking for county histories on Googlebooks or Internet Archives and then adding them to the County pages
Projects[edit | edit source]
- There are several on-going projects in the Wiki. There will be information for areas where help is needed. Many of the tasks are appropriate for a beginner.
Get Started[edit | edit source]
See the topics below for ideas about how you can help on the wiki. Volunteers should also contact the Moderator for the State, Country and Possessions of interest for suggestions and help for contributions associated for that location.
Wiki Editor Training[edit | edit source]
Learn all about editing, and get started by adding something to improve the wiki. To learn all about editing in the wiki, click on each of the following in turn and follow the steps there:
Editing in the wiki
Talk with other contributors
- Join the Contributor Community:
- On FamilySearch Groups: Request an invitation | Go to FS Wiki group
(FS Groups requires you to be invited to join; fill out the form to request an invitation, or go directly to the FS Wiki group if you've already joined.)
- On FamilySearch Groups: Request an invitation | Go to FS Wiki group
- Learn about Talk pages
- Create your Wiki User page: Example One | Example Two | Example Three
- Add the Volunteer Userbox to your user page
- Join the Contributor Community:
Enrich your experience
Help[edit | edit source]
- Help is available as you determine a task that you would like to do:
- Contributor Help
- Questions? (including Mentoring)
Learn more about ...[edit | edit source]
Projects Seeking Contributors
Maintaining the Help Content Committee
Maintenance and Patrolling Committee
Enhancement Committee


text:
Grow your company
by accessing our global
youth network
Access diverse and dynamic young leaders.
Access diverse and dynamic young leaders.
Each year over 5,000 companies around the world trust AIESEC to provide high calibre, international student and graduate interns
We host a number of conferences and meet-ups where businesses can connect and collaborate with students across the globe
Through surveys, events and focus groups we enable businesses to learn about youth markets to help them shape their products and messaging
corporate partners
professional placements (2013)
internships so far
Five reasons to source your interns from AIESEC
We can connect your company to a global talent pool of over 100,000 bright young people
Our interns bring language skills and regional insight to help you build your business in new territories
Many of our interns are familiar with office life and quickly add value, having already taken a role within the AIESEC team
AIESECers have well-established facilitation, problem-solving and communication skills
Our teams learn the value of continuous personal development and bring with them a natural desire to learn
We can save you time, source the right candidates and help strengthen your talent pipeline
Help you detail the role and applicant you're looking for
We will promote your opportunity to help acquire a list of suitable candidates
We will pre-screen candidates to save you time prior to interviews
Visa and
We facilitate relevant visas through our long-established partnerships with governments
Intern support
Our local team will be on hand to welcome and assist your intern when they arrive
Find out how we can help you
Get in touch now
Sourcing interns or working as a corporate partner with AIESEC is simple.
Fill in your business details below and an AIESEC representative will get back to you shortly.


text: The birthday books can be personalised with any name,message and special details. They are unique keepsake gifts. They are 24.5cm wide x 17cm high. They have a white textured hard cover with white high quality plain paper inside. The memory books are packaged in a clear fronted box; they are ideal gifts for a special occasion.


text:
Automated Wiring of Message-Passing Processes
A CHP program consists of many concurrent processes, wired together. They can be wired together with channels of any type (here, colour indicates the type the channel carries) that may be connected in one direction or the other:
They can also be joined with non-phased barriers (which come in one colour, black):
Connection Example 1
Now consider this pair of processes, p that requires an incoming purple channel and outgoing red channel, and q that requires an incoming red channel and outgoing green channel:
It is incredibly obvious what is needed to wire them up: a red channel from p to q. Once the two processes are connected in this way, they will become a new process, r, that requires an incoming purple channel (which will be passed to p) and an outgoing green channel (which will be passed to q):
Connection Example 2
It remains obvious even for this slightly more complicated example, where p requires an incoming purple channel and a pair (outgoing red channel, incoming blue channel), and q requires a pair (incoming red channel, outgoing blue channel) and a pair (outgoing green channel, incoming beige channel):
Their composition into r is:
Connection Example 3
Finally, there is an example where p takes one argument — a pair (outgoing red channel, enrolled barrier) — and q takes two arguments — a pair (incoming red channel, enrolled barrier), and an Int:
They compose into a process that only requires one argument, the Int:
Connectable Operators
It is child's play to work out how to connect the processes — and the user code should be just as easy. I recently added the Connectable type-class to CHP to facilitate this kind of simple wiring. I'll come to the implementation, but first here are the examples again, along with the code to wire them up (the type for r can be inferred from the type of p and q, but I give all the types anyway):
p :: Chanin Purple -> Chanout Red -> CHP () q :: Chanin Red -> Chanout Green -> CHP () r :: Chanin Purple -> Chanout Green -> CHP () r = p <=> q
p :: Chanin Purple -> (Chanout Red, Chanin Blue) -> CHP () q :: (Chanin Red, Chanout Blue) -> (Chanout Green, Chanin Beige) -> CHP () r :: Chanin Purple -> (Chanout Green, Chanin Beige) -> CHP () r = p <=> q
p :: (Chanout Red, EnrolledBarrier) -> CHP () q :: (Chanin Red, EnrolledBarrier) -> Int -> CHP () r :: Int -> CHP () r = p |<=> q
Note that the <=> operator is for when both processes take two parameters, and there are slight variants for other situations; for example, |<=> for when the left-hand side only takes one parameter (the bar indicates that this could be at the left-hand end of a pipeline of such processes).
Connectable Implementation
The implementation is simple enough that I will show it here. We have our Connectable type-class:
class Connectable l r where connect :: ((l, r) -> CHP a) -> CHP a
Given a CHP process requiring the two things connected, it will connect them for the duration of the process and run it. So we have simple instances for channels and barriers:
instance Connectable (Chanout a) (Chanin a) where connect p = newChannelWR >>= p instance Connectable (Chanin a) (Chanout a) where connect p = newChannelRW >>= p instance Connectable EnrolledBarrier EnrolledBarrier where connect p = do b <- newBarrier enroll b $ \b0 -> enroll b $ \b1 -> p (b0, b1)
Then the real power comes from the instances for pairs, triples and so on:
instance (Connectable al ar, Connectable bl br) => Connectable (al, bl) (ar, br) where connect p = connect (\(ax, ay) -> connect (\(bx, by) -> p ((ax, bx), (ay, by))))
This instance means that any two corresponding pairs of connectable things are also connectable. This means that we can define our useful process composition operator and use it everywhere on all sorts of types:
(<=>) :: Connectable l r => (a -> l -> CHP ()) -> (r -> b -> CHP ()) -> a -> b -> CHP () (<=>) p q x y = p x |<=>| flip q y (|<=>|) :: Connectable l r => (l -> CHP ()) -> (r -> CHP ()) -> CHP () (|<=>|) p q = connect (\(x, y) -> p x <|*|> q y)
Now that we have this notion of connectable things, we can define further functions to connect a list of processes in a pipeline and so on (these are provided for you in CHP). My favourite function, which is required very often if you build 2D simulations, is the wrappedGrid operator, forthcoming in CHP 1.8.0. Given a data-type to represent 4-way connectivity:
data FourWay above below left right = FourWay { above :: above, below :: below, left :: left, right :: right }
And provided above can connect to below, and left to right, we can wire up a list of lists of processes (i.e. a 2D grid in waiting) into a torus, that is a grid where the top edge connects to the bottom edge and the left edge to the right edge (as is often the case in old arcade games):
wrappedGrid :: (Connectable above below, Connectable left right) => [[FourWay above below left right -> CHP a]] -> CHP [[a]]
The implementation is a little fiddly — but I can define it once in the CHP library, and you can use it with whatever channels and barriers you use to connect up your four-way wrapped-round 2D grid. I'm also going to define a similar operator for 8-way connectivity. By capturing the notion of two things being connectable, we are able to build operators and helper functions for such common topologies without caring whether the individual components are connected by channels of Ints, Strings, MyCustomDataType or by barriers.
December 6, 2009 at 12:38 pm
December 21, 2009 at 3:02 pm
January 19, 2010 at 1:41 pm
March 28, 2010 at 9:40 pm
January 10, 2011 at 12:37 pm


text:
A few months ago I had the privilege of meeting Vlad Sokhin, a documentary photographer here in Port Moresby. As a member of the PNG Photography Association, I was very happy to be part of the group that turned up to meet him and view some of his work. It was a very educational and also interesting to find out what documentary photography was about and of course meeting Vlad in person.
Here dwarfed by Vlad, I couldn't imagine that in 2013 I would be standing in the shadow of this iconic person. Winner of over 10 prestigious awards.
Vlad showed us some videos he had taken in Portugal, and a number of countries in Africa and elsewhere. I was fascinated at what his lens conveyed in pictures many ordinary lives of extraordinary people. I left before we got to Vlad's photographs on specific themes here in Papua New Guinea.
I wish Vlad all the best in his future photography endeavours here and abroad.
Vlad is working on a project here locally in Port Moresby and environs so I wish him the best in that project.