Not without reading the source code and patching it at a very deep level.
In our setup we use virtual tables almost exclusively and these do not support
transactions. There are also dedicated writers for each set of tables, so table
locking outside of SQLite is sufficient. The only changes that
Hi ,
I see that in release history for 3.8.1 below item.
"Estimate the sizes of table and index rows and use the smallest applicable
B-Tree for full scans and "count(*)" operations."
Does it mean that performance of count(*) has been improved in 3.8.1 and if yes
by how much? We were using
On Mon, 25 Nov 2013 19:44:15 +0100
Luuk wrote:
> On 25-11-2013 13:41, Simon Slavin wrote:
> > I'm wondering whether there's an argument that it should be
> > evaluated just once for a transaction.
>
> I'm still thinking about this question,
>
> i can think of some benefits if
SQLite version 3.8.2 is tentatively scheduled for release on 2013-12-10.
That date can move in either direction.
Snapshots of the latest beta code can be obtained from the
http://www.sqlite.org/download.html download page. A summary of changes in
the 3.8.2 release can be seen at
And you can't execute it at all if any of the attached databases are read-only.
Peter
>On 11/26/2013 2:24 PM, Joshua Grauman wrote:
>> If I have multiple databases attached and then do a:
>> BEGIN EXCLUSIVE
>>
>> I assume all the sqlite3 tables involved get locked?
>
>All the database files
On 11/26/2013 2:24 PM, Joshua Grauman wrote:
If I have multiple databases attached and then do a:
BEGIN EXCLUSIVE
I assume all the sqlite3 tables involved get locked?
All the database files are locked.
Is there a way to lock only one of the attached tables?
I'm pretty sure there isn't,
Hello all,
If I have multiple databases attached and then do a:
BEGIN EXCLUSIVE
I assume all the sqlite3 tables involved get locked?
Is there a way to lock only one of the attached tables?
Thanks.
___
sqlite-users mailing list
sqlite-users@sqlite.org
Checkin http://www.sqlite.org/src/info/6f53fc7106 is an important behavior
change for SQLite.
The check-in above changes the behavior of REAL-to-INTEGER casts where the
REAL value is larger than the largest possible integer. For example:
SELECT CAST(9223372036854775808.0 to INTEGER);
All
On Tue, Nov 26, 2013 at 6:39 AM, Jan Staněk wrote:
> Hello,
> I'm trying to build sqlite for aarch64 (ARMv8) and one of the expression
> tests is failing (specifically e_expr-31.2.4) with:
> > Expected: [integer -9223372036854775808]
> > Got: [integer
Jan Staněk wrote:
> I'm trying to build sqlite for aarch64 (ARMv8) and one of the expression
> tests is failing (specifically e_expr-31.2.4) with:
>> Expected: [integer -9223372036854775808]
>> Got: [integer 9223372036854775807]
> From the comment, I gather that this should test correct
Hello,
I'm trying to build sqlite for aarch64 (ARMv8) and one of the expression
tests is failing (specifically e_expr-31.2.4) with:
> Expected: [integer -9223372036854775808]
> Got: [integer 9223372036854775807]
>From the comment, I gather that this should test correct CASTing from
REAL to
>> 2) SqliteDataReader.GetOrdinal()
> This does not appear to be entirely compatible, most notable due to not
> taking the keyInfo into account.
Sorry, I forgot that we eliminated all keyInfo-related code.
Anyway, it still would make sense to extend caching to all column names that
were
Ah ok, I thought the Xerial driver no longer supported the nestedvm
stuff. What you'll need to do is compile the Xerial binary for Solaris.
See https://bitbucket.org/xerial/sqlite-jdbc/wiki/Home#BuildfromSource
for details.
Pepijn
On 11/26/2013 06:48 AM, Liang Kunming wrote:
Hi, Pepijn,
13 matches
Mail list logo