The current implementation will only support a string or BLOB length up to 231-1 or 2147483647. You can raise or lower this value at compile-time using a command-line option like this: The default value of this macro is 1 billion (1 thousand million or 1,000,000,000). The maximum number of bytes in a string or BLOB in SQLite is defined by the preprocessor macro SQLITE_MAX_LENGTH.
DB BROWSER FOR SQLITE SIZE OF TABLE CODE
The sqlite3_limit() interface allows internal databases managed by trusted code to be unconstrained while simultaneously placing tight limitations on databases created or controlled by untrusted external code in order to help prevent a denial of service attack. For example, a web browser application might use an internal database to track historical page views but have one or more separate databases that are created and controlled by javascript applications that are downloaded from the internet. Run-time limits are designed for applications that have multiple databases, some of which are for internal use only and others which can be influenced or controlled by potentially hostile external agents.
Some limits can be changed at run-time on a per-connection basis using the sqlite3_limit() interface with one of the limit categories defined for that interface.
More commonly, an application might want to recompile SQLite with much lower limits to avoid excess resource utilization in the event of bug in higher-level SQL statement generators or to help thwart attackers who inject malicious SQL statements. Some applications may want to increase a limit here or there, but we expect such needs to be rare. The default settings for limits are normally quite large and adequate for almost every application. This article defines what the limits of SQLite are and how they can be customized for specific applications. For this reason, newer versions of SQLite have well-defined limits and those limits are tested as part of the test suite. Because the upper bounds were not well defined, they were not tested, and bugs (including possible security exploits) were often found when pushing SQLite to extremes. Unfortunately, the no-limits policy has been shown to create problems. The policy was that if it would fit in memory and you could count it with a 32-bit integer, then it should work. But in SQLite, those limits were not well defined. Of course, every program that runs on a machine with finite memory and disk space has limits of some kind. SQLite was originally designed with a policy of avoiding arbitrary limits. We are concerned with things like the maximum number of bytes in a BLOB or the maximum number of columns in a table. "Limits" in the context of this article means sizes or quantities that can not be exceeded. The C language interface to SQLite Version 2 Upgrading SQLite, Backwards Compatibility Locking And Concurrency In SQLite Version 3 NULL Handling in SQLite Versus Other Database Engines An Introduction To The SQLite C/C++ InterfaceĬ-language Interface Specification for SQLite
0 kommentar(er)
