Lines Matching +defs:major +defs:mode
195 ** checkpointing the database in WAL mode.
641 ** format "X.Y.Z" where X is the major version number (always 3 for
763 ** See the [threading mode] documentation for additional information.
1318 ** closes. Setting persistent WAL mode causes those files to persist after
1324 ** That integer is 0 to disable persistent WAL mode or 1 to enable persistent
1325 ** WAL mode. If the integer is -1, then it is overwritten with the current
1833 ** [threading mode] to Single-thread. In other words, it disables
1834 ** all mutexing and puts SQLite into a mode where it can only be used
1837 ** it is not possible to change the [threading mode] from its default
1844 ** [threading mode] to Multi-thread. In other words, it disables
1852 ** it is not possible to set the Multi-thread [threading mode] and
1858 ** [threading mode] to Serialized. In other words, this option enables
1861 ** In this mode (which is the default when SQLite is compiled with
1868 ** it is not possible to set the Serialized [threading mode] and
2967 ** <dd>The database is opened in read-only mode. If the database does not
2987 ** opens in the multi-thread [threading mode] as long as the single-thread
2988 ** mode has not been set at compile-time or start-time. ^If the
2990 ** in the serialized [threading mode] unless single-thread was
2993 ** eligible to use [shared cache mode], regardless of whether or not shared
2996 ** participate in [shared cache mode] even if it is enabled.
3056 ** <li> <b>mode</b>: ^(The mode parameter may be set to either "ro", "rw" or
3060 ** third argument to sqlite3_prepare_v2(). ^If the mode option is set to
3065 ** used, it is an error to specify a value for the mode parameter that is
3102 ** <tr><td> file:data.db?mode=ro&cache=private <td>
3104 ** Regardless of whether or not shared-cache mode is enabled by
3108 ** <tr><td> file:data.db?mode=readonly <td>
3109 ** An error. "readonly" is not a valid option for the "mode" parameter.
3181 ** When the serialized [threading mode] is in use, it might be the
4870 ** KEYWORDS: {autocommit mode}
4873 ** zero if the given database connection is or is not in autocommit mode,
4874 ** respectively. ^Autocommit mode is on by default.
4875 ** ^Autocommit mode is disabled by a [BEGIN] statement.
4876 ** ^Autocommit mode is re-enabled by a [COMMIT] or [ROLLBACK].
5030 ** ^(The cache sharing mode set by this interface effects all subsequent
5032 ** Existing database connections continue use the sharing mode
5686 ** database connection is in [autocommit mode].
6075 ** when the [threading mode] is Serialized.
6076 ** ^If the [threading mode] is Single-thread or Multi-thread then this
6362 ** [shared cache mode] being enabled.
6799 ** If running in [shared cache mode], the application must
6827 ** ^When running in shared-cache mode, a database operation may fail with
6984 ** [journal_mode | journal_mode=WAL mode]).
7053 ** [WAL | write-ahead log mode] then this interface is a harmless no-op.
7075 ** are checkpointed. This mode is the same as calling
7079 ** This mode blocks (calls the busy-handler callback) until there is no
7086 ** This mode works the same way as SQLITE_CHECKPOINT_FULL, except after
7130 ** mode, SQLITE_OK is returned and both *pnLog and *pnCkpt set to -1. If
7187 ** ON CONFLICT mode specified.
7192 ** If the [ON CONFLICT] mode is ABORT, FAIL, IGNORE or ROLLBACK, SQLite
7195 ** If the ON CONFLICT mode is REPLACE and the [xUpdate] method returns
7196 ** [SQLITE_CONSTRAINT], SQLite handles this as if the ON CONFLICT mode
7217 ** [SQLITE_ABORT], or [SQLITE_REPLACE], according to the [ON CONFLICT] mode
7227 ** inform a [virtual table] implementation what the [ON CONFLICT] mode
9321 ** In shared cache mode, a single Schema object can be shared by multiple
9391 ** be stored in lookaside because in shared cache mode the schema information
9458 u8 dfltLockMode; /* Default locking-mode for attached dbs */
9579 #define SQLITE_ReadUncommitted 0x0080000 /* For shared-cache mode */
10180 u8 directMode; /* Direct rendering mode means take data directly
10182 u8 useSortingIdx; /* In direct mode, reference the sorting index rather
10362 ** routine is implemented as a macro that only works when in debugging mode,
10868 TableLock *aTableLock; /* Required table locks for shared-cache mode */
11099 int sharedCacheEnabled; /* true if shared-cache mode enabled */
20675 ** point precision mode other than /fp:precise. From the MSDN
23284 ULONG mode, timeout;
23289 mode = 1; /* shared lock */
23298 mode = 0; /* exclusive lock */
23301 NULL, &area, timeout, mode);
23909 int flags, /* Open mode flags */
23986 /* Open in random access mode for possibly better speed. Allow full
24614 /* In test mode, increase the size of this structure a bit so that
24626 #define UNIXFILE_PERSIST_WAL 0x04 /* Persistent WAL mode */
24881 static int posixOpen(const char *zFile, int flags, int mode){
24882 return open(zFile, flags, mode);
26403 ** This locking mode is appropriate for use on read-only databases
26408 ** corruption if this locking mode is used in situations where multiple
26450 ** Nevertheless, a dotlock is an appropriate locking mode for use if no
32406 /* The following blocks should probably assert in debug mode, but they
34011 int flags, /* Open mode flags */
35819 ** For mode (1), PGroup.mutex is NULL. For mode (2) there is only a single
35948 PGroup grp; /* The global PGroup for mode (2) */
36572 ** PGroup. In other words, separateCache is true for mode (1) where no
36575 ** * Always use a unified cache (mode-2) if ENABLE_MEMORY_MANAGEMENT
36580 ** use separate caches (mode-1)
37721 ** rollback (non-WAL) mode are met. Unless the pager is (or recently
37722 ** was) in exclusive-locking mode, a user-level read transaction is
37749 ** In rollback mode, a RESERVED or (if the transaction was opened with
37756 ** IN WAL mode, WalBeginWriteTransaction() is called to lock the log file.
37761 ** * If the connection is open in rollback-mode, a RESERVED or greater
37763 ** * If the connection is open in WAL-mode, a WAL write transaction
37774 ** first modified by the upper layer. In rollback mode the journal file
37802 ** A rollback-mode pager changes to WRITER_FINISHED state from WRITER_DBMOD
37877 ** connection is open in WAL mode. A WAL connection is always in one
37880 ** * Normally, a connection open in exclusive mode is never in PAGER_OPEN
37881 ** state. There are two exceptions: immediately after exclusive-mode has
38029 ** This mechanism means that when running in exclusive mode, a connection
38041 ** committed or rolled back when running in "journal_mode=PERSIST" mode.
38046 ** running in "journal_mode=truncate" mode.
38164 ** significant mode change (such as changing the page_size, locking_mode,
38359 /* If the useJournal flag is clear, the journal-mode must be "OFF".
38360 ** And if the journal-mode is "OFF", the journal file must not be open.
38484 "Locking mode: locking_mode=%s\n"
38485 "Journal mode: journal_mode=%s\n"
38813 ** if the pager is not in no-sync mode, sync the journal file immediately
38866 ** - 4 bytes: Number of records in journal, or -1 no-sync mode is on.
38903 ** if in full-sync mode), the zero is overwritten with the true number
38913 ** * When the pager is in no-sync mode. Corruption can follow a
39101 ** thing written to a journal file. If the pager is in full-sync mode, the
39142 /* If in full-sync mode, advance to the next disk sector before writing
39164 /* If the pager is in peristent-journal mode, then the physical
39208 ** if it is open and the pager is not in exclusive mode.
39245 ** This function is a no-op if the pager is in exclusive mode and not
39249 ** If the pager is not in exclusive-access mode, the database file is
39256 ** the OPEN state. Regardless of whether the pager is in exclusive-mode
39319 ** normal and exclusive-locking mode.
39344 ** all major API calls on the Pager will immediately return Pager.errCode.
39385 ** depends on whether or not the pager is running in exclusive mode and
39386 ** the current journal-mode (Pager.journalMode value), as follows:
39403 ** If the pager is running in exclusive mode, this method of finalizing
39405 ** DELETE and the pager is in exclusive mode, the method described under
39409 ** If running in non-exclusive rollback mode, the lock on the file is
39416 ** tries to unlock the database file if not in exclusive mode. If the
39501 ** locking_mode=exclusive mode but is no longer, drop the EXCLUSIVE
39715 ** An exception to the above rule: If the database is in no-sync mode
39786 ** obscure. When running in synchronous mode, this can only happen
40192 ** working in no-sync mode. This means that the rest of the journal
40282 ** mode, then subsequent transactions performed by the connection will not
40638 ** in WAL mode. If the database is empty or if no *-wal file exists and
40852 ** single disk sector is atomic, then this mode provides
40856 ** The above is for a rollback-journal mode. For WAL mode, OFF continues
40861 ** an ordinary commit in NORMAL mode with WAL. FULL means that the WAL
41127 ** to WAL mode yet.
41349 ** Otherwise, the actions required depend on the journal-mode and the
41359 ** mode, then the journal file is synced before this field is updated.
41368 ** if( <full-sync mode> ) xSync(<journal file>);
41399 ** mode, then the journal file may at this point actually be larger
41437 ** full-synchronous mode, sync the journal first. This ensures that
41479 /* Unless the pager is in noSync mode, the journal file was just
42229 ** 2) If the pager is running in exclusive-mode, and there are currently
42245 ** exclusive access mode.
42288 ** Unless the pager is in locking_mode=exclusive mode, the lock is
42298 ** in exclusive-access mode the file descriptor will be kept open
42301 ** mode (and also for journal_mode=truncate on some systems).
42414 ** mode. Otherwise, the following function call is a no-op.
42656 ** If the journal file is already open (as it may be in exclusive mode),
42745 ** running in exclusive mode) or if the transaction does not require a
42793 ** WAL mode sets Pager.eState to PAGER_WRITER_LOCKED or CACHEMOD
42798 ** WAL mode.
43152 ** operating in direct-mode, make page 1 writable. When not in
43153 ** direct mode, page 1 is always held in cache and hence the PagerGet()
43164 /* If running in direct mode, write the contents of page 1 to the file. */
43207 ** rollback. If the connection is in WAL mode, this call is a no-op.
43212 ** successful, or the connection is in WAL mode, SQLITE_OK is returned.
43318 ** counter in 'indirect-mode'. If the optimization is compiled in but
43322 ** mode.
43326 ** in 'direct' mode. In this case the journal file will never be
43360 ** file. This can only happen in auto-vacuum mode.
43474 ** this transaction, the pager is running in exclusive-mode and is
43481 ** header. Since the pager is in exclusive mode, there is no need
43507 ** Otherwise, in rollback mode, this function performs two functions:
43519 ** In WAL mode, all cache-entries containing data modified within the
43996 ** Get/set the locking-mode for this pager. Parameter eMode must be one
43999 ** the locking-mode is set to the value specified.
44003 ** locking-mode.
44019 ** Set the journal-mode for this pager. Parameter eMode must be one of:
44036 ** The returned indicate the current (possibly updated) journal-mode.
44058 ** to WAL mode.
44074 /* Change the journal mode. */
44079 ** mode except WAL, unless the pager is in locking_mode=exclusive mode,
44127 /* Return the new journal mode */
44132 ** Return the current journal mode.
44227 ** exclusive-locking mode when this function is called, take an EXCLUSIVE
44237 /* If the pager is already in exclusive-mode, the WAL module will use
44307 ** to switching from WAL to rollback mode.
44321 ** rollback mode. Open it now so this can happen.
44384 ** "journal_mode=WAL" mode.
44789 u8 exclusiveMode; /* Non-zero if connection is in exclusive mode */
45617 int bNoShm, /* True to run in heap-memory mode */
45988 ** SQLite is in WAL-mode in synchronous=NORMAL. That means that if
46167 ** ordinary, rollback-mode locking methods, this guarantees that the
47259 ** transition out of exclusive-mode is successful, return 1. This
47266 ** WAL is already in exclusive-locking mode - meaning that this
47282 ** happen if the connection is actually in exclusive mode (as no xShmLock
47284 ** upgrade to exclusive-mode following such an error.
47421 ** 64 4 Incremental vacuum mode
48564 ** by a connection in read-uncommitted mode is on the sqlite_master
49955 ** and we are in shared cache mode, then the open will fail with an
50064 /* In debug mode, we mark all persistent databases as sharable
50116 ** leave the autoVacuum mode at 0 (do not auto-vacuum), even if
50418 ** and autovacuum mode can no longer be changed.
50501 ** parameter is non-zero, then auto-vacuum mode is enabled. If zero, it
50602 ** in WAL mode. If the log is not already open, open it now. Then
52087 ** mode, the following events may invalidate an overflow page-list cache.
52090 ** * A commit in auto_vacuum="full" mode,
53475 ** freePage2() may zero the page contents if secure-delete mode is
54223 ** Unless SQLite is compiled in secure-delete mode. In this case,
55455 ** database. This is because in auto-vacuum mode the backend may
56773 int destMode; /* Destination journal mode */
56817 /* Do not allow backup if the destination database is in WAL mode
59285 ** If SQLite is compiled to support shared-cache mode and to be threadsafe,
59291 ** If SQLite is not threadsafe but does support shared-cache mode, then
59296 ** If SQLite is not threadsafe and does not support shared-cache mode, this
60400 ** has made changes and is in autocommit mode, then commit those
64031 Btree *pBt; /* Btree to change journal mode of */
64033 int eNew; /* New journal mode */
64034 int eOld; /* The old journal mode */
66397 ** connection is currently not in autocommit mode, or if there are other
66626 ** in read/write mode. For a given table, there can be one or more read-only
67454 assert( pOp->p3==0 ); /* We cannot be in random rowid mode if this is
69026 ** WAL mode. Parameter P2 is one of SQLITE_CHECKPOINT_PASSIVE, FULL
69062 ** Change the journal mode of database P1 to P3. P3 must be one of the
69067 ** If changing into or out of WAL mode the procedure is more complicated.
69069 ** Write a string containing the final journal-mode to register P2.
69073 Btree *pBt; /* Btree to change journal mode of */
69075 int eNew; /* New journal mode */
69076 int eOld; /* The old journal mode */
69116 "cannot change %s wal mode from within a transaction",
69123 /* If leaving WAL mode, close the log file. If successful, the call
69133 /* Cannot transition directly from MEMORY to WAL. Use mode OFF
69139 ** mode, this transaction always uses a rollback journal.
81261 ** move as a result of the drop (can happen in auto-vacuum mode).
90018 ** Interpret the given string as a locking mode value.
90030 ** Interpret the given string as an auto-vacuum mode value.
90179 ** in auto-commit mode. */
90226 ** journal-mode name.
90449 ** the current default locking mode (which may be different to
90450 ** the locking-mode of the main database).
90457 ** of the PRAGMA command. In this case the locking-mode must be
90462 ** locking mode.
90506 ** current mode */
90515 /* If the "=MODE" part does not match any known journal mode,
90587 /* When setting the auto_vacuum mode to either "full" or
91724 ** meta[3] Largest rootpage (auto/incr_vacuum mode)
91727 ** meta[6] Incremental vacuum mode
92951 /* In this mode, write each query result to the key of the temporary
100293 ** Return the ON CONFLICT resolution mode in effect for the virtual
106378 ** (In other words, the "major" token.)
106386 YYCODETYPE major; /* The major token value. This is the code
107000 ** Return the major token number for the symbol popped.
107013 yyTokenName[yytos->major]);
107016 yymajor = yytos->major;
107186 int yyMajor, /* The major token to shift in */
107212 yytos->major = (YYCODETYPE)yyMajor;
107220 fprintf(yyTraceFILE," %s",yyTokenName[yypParser->yystack[i].major]);
107639 {yygotominor.yy4 = yymsp[0].major;}
108144 {spanExpr(&yygotominor.yy118, pParse, yymsp[0].major, &yymsp[0].minor.yy0);}
108240 {spanBinaryExpr(&yygotominor.yy118,pParse,yymsp[-1].major,&yymsp[-2].minor.yy118,&yymsp[0].minor.yy118);}
108276 {spanUnaryPostfix(&yygotominor.yy118,pParse,yymsp[0].major,&yymsp[-1].minor.yy118,&yymsp[0].minor.yy0);}
108295 {spanUnaryPrefix(&yygotominor.yy118,pParse,yymsp[-1].major,&yymsp[0].minor.yy118,&yymsp[-1].minor.yy0);}
108520 {yygotominor.yy90.a = yymsp[0].major; yygotominor.yy90.b = 0;}
108730 yymsp->major = (YYCODETYPE)yygoto;
108768 int yymajor, /* The major type of the error token */
108802 ** The second argument is the major token number. The third is
108810 ** <li> The major token number.
108820 int yymajor, /* The major token code number */
108846 yypParser->yystack[0].major = 0;
108900 yymx = yypParser->yystack[yypParser->yyidx].major;
111595 ** not currently open in WAL mode.
111958 ** "cache=xxx" or "mode=xxx" query parameters.
112093 int mode;
112111 if( nOpt==4 && memcmp("mode", zOpt, 4)==0 ){
112127 int mode = 0;
112131 mode = aMode[i].mode;
112135 if( mode==0 ){
112136 *pzErrMsg = sqlite3_mprintf("no such %s mode: %s", zModeType, zVal);
112140 if( mode>limit ){
112141 *pzErrMsg = sqlite3_mprintf("%s mode not allowed: %s",
112146 flags = (flags & ~mask) | mode;
112407 ** mode. -DSQLITE_DEFAULT_LOCKING_MODE=0 make NORMAL the default locking
112408 ** mode. Doing nothing at all also makes NORMAL the default.
112609 ** mode. Return TRUE if it is and FALSE if not. Autocommit mode is on
119889 unsigned char parenOnly; /* Only valid in paren mode */
120112 Fts3Expr *pNotBranch = 0; /* Only used in legacy parse mode */
120598 ** Hash and comparison functions when the mode is FTS3_HASH_STRING
120616 ** Hash and comparison functions when the mode is FTS3_HASH_BINARY
125423 ** If the on-conflict mode is REPLACE, this means that the existing row
125425 ** if the on-conflict mode is other than REPLACE, then this method must
125443 ** rowid column. So if the conflict mode is REPLACE, then delete any
125446 ** Or, if the conflict mode is not REPLACE, insert the new record into
129764 ** In the first case, if the conflict-handling mode is REPLACE, then
129767 ** conflict-handling mode specified by the user.