[sqlite] SQLite database becomes corrupt on iOS

On Aug 14, 2015, at 10:13 AM, Simon Slavin wrote: > On 14 Aug 2015, at 5:16pm, Random Coder wrote: >> I've run into other issues >> that lead me to believe the OS is caching file writes until the app >> exits in some situations regardless of various sync calls, but I never >> did have time to

[sqlite] SQLite database becomes corrupt on iOS

On Aug 19, 2015, at 11:34 PM, Simon Slavin wrote: > > > On 20 Aug 2015, at 6:22am, Scott Perry wrote: > >> That said, it's possible to corrupt a database by forcing the device to >> power off (by holding the power and home buttons) while SQLite's writes are >>

[sqlite] SQLite take lower performance while using shared cache on iOS/Mac

Using a shared cache will result in lower memory usage and may result in lower IO, but it isn't likely to speed up your program since it also requires more locks to guarantee safety between competing database connections. SQLite on Apple's platforms is built with SQLITE_THREADSAFE=2, so under

[sqlite] static malloc_zone_t* _sqliteZone_

Good eye, thanks for reporting this. Pointers on the stack or in static storage are pointer-aligned by default on all of Apple's platforms. On Mar 3, 2015, at 7:27 PM, Andy Rahn wrote: > > Hi SQLite users; > > I have a question about _sqliteZone_ in mem1.c. I notice that the > address of

[sqlite] Integrating sqlite with Core Data and iCloud

There are a lot of people who go on this journey, and I don't recommend it. If you want to take advantage of iCloud, it's best to use Core Data directly, perhaps with an API shim of your own making that makes it easier and more suitable to your needs. On Apr 25, 2015, at 12:41 PM, Jeff M

[sqlite] Copying an open DB file (iOS)

On May 8, 2015, at 4:47 AM, Simon Slavin wrote: > On 8 May 2015, at 8:09am, Jeff M wrote: > >> For a restore, the current DB is closed, then a backup file is copied in and >> opened. > >> I've been using this scheme for years without a problem. But, should I >> flush, or close, or lock

[sqlite] {Spam?} SQLite take lower performance while usingshared cache on iOS/Mac

The SQLite built into OS X does not support cache sharing for performance reasons?, which is probably why your results are statistically identical and the OP's results are wildly different. You can verify this by checking the return value of sqlite3_enable_shared_cache; on OS X it returns

[sqlite] Article about pointer abuse in SQLite

On Mar 21, 2016, at 3:17 AM, Klaas Van B. wrote: > >>> On 3/19/16, James K. Lowden wrote: > >>> ... If the correctness of the code is >>> subject to change by the compiler's interpretation of the language, how >>> is the programmer to prevent it? > >> On Sat, 19 Mar 2016 15:50:43 -0400

[sqlite] Article about pointer abuse in SQLite

On Mar 21, 2016, at 1:48 PM, Scott Perry wrote: > > On Mar 21, 2016, at 3:17 AM, Klaas Van B. wrote: >> >>>> On 3/19/16, James K. Lowden wrote: >> >>>> ... If the correctness of the code is >>>> subject to change by the compiler's inte

Re: [sqlite] .timer command missing from CLI ?

On Feb 15, 2017, at 11:46 AM, Simon Slavin wrote: > On 15 Feb 2017, at 7:39pm, Richard Hipp wrote: >> Are you saying it is the one built into MacOS - not one you obtained >> from https://www.sqlite.org/download.html? If so, can you provide me >> with

Re: [sqlite] Regarding CoC

I have to admit I was a lot more excited about the concept of SQLite having a Code of Conduct until I actually read it. Regardless of the fact that I seem to fail a great many of its provisions, it seems fairly deaf—if not antagonistic—to the issues of our times that have created demand for

Re: [sqlite] CoreData - when database gets closed

On Jan 22, 2019, at 9:02 AM, Simon Slavin wrote: > > On 22 Jan 2019, at 3:45pm, Maldonado-Salazar, Carlos > wrote: > >> Is there a way to know when CoreData closes sqlite files?. I’m using >> CoreData in an iOS app and I set file attributes for sqlite file to be >>

Re: [sqlite] Mac: Users receive "database disk image is malformed" errors after restoring database from Time Machine backup

On Dec 11, 2018, at 04:01, Daniel Alm wrote: > > Hi, > > For the past half year we’ve been receiving reports from users who had > restored their SQLite-based databases from a Time Machine backup. Afterwards, > they would receive "database disk image is malformed” errors. The app also > backs

Re: [sqlite] SQLite iOS timestamp type mapping settings must be set to float to get correct data

On Nov 26, 2018, at 14:16, Simon Slavin wrote: > > On 26 Nov 2018, at 9:09pm, Scott Perry wrote: > >> For Bill's purposes—investigating a copied, non-corrupt database—it would >> probably be easiest to just convert from the Cocoa epoch to the Unix epoch >>

Re: [sqlite] SQLite iOS timestamp type mapping settings must be set to float to get correct data

On Nov 20, 2018, at 12:41 PM, Jens Alfke wrote: > On Nov 20, 2018, at 11:44 AM, Bill Hashman > wrote: > >> The timestamp from iOS systems is not compliant with ISO 8601/Unix or other >> common timestamps. It appears apple has their start date offset 31 years. > > Yes, the ‘epoch’ in

Re: [sqlite] Backing up a SQLite database without the CLI

`ATTACH` and iterating over all tables with `INSERT INTO SELECT` is how `VACUUM INTO` is implemented (see src/vacuum.c). A less complicated way to back up the database might be to run `BEGIN` followed by `PRAGMA user_version` to acquire a read lock, after which you can safely copy the database

Re: [sqlite] SEE Temp Files

> On Jan 29, 2019, at 10:12, Jens Alfke wrote: > >> On Jan 28, 2019, at 3:35 PM, Richard Hipp wrote: >> >> On the other >> hand, if you set SQLITE_TEMP_STORE=2 so that intermediate results are >> held in memory, then intermediate results may be written to swap space >> when the device gets

Re: [sqlite] -wal and -shm files left behind by libsqlite3.dylib

This is expected behaviour. As Richard guessed, the system libsqlite3.dylib is built with SQLITE_ENABLE_PERSIST_WAL. For Darwin systems, the compromise of keeping the extra 4MiB (max) file around is generally worth the reduced I/O overhead that results from creating, resizing, and unlinking

Re: [sqlite] Corruption of database when renaming a table

The behaviour of ALTER TABLE changed in 3.25.0 and breaks compatibility with many existing applications. Your statements (corrected for use of single quotes, as Ryan mentioned) work for me when `PRAGMA legacy_alter_table=1;`. More info on SQLite's website:

Re: [sqlite] DEF CON (wasL A license plate of NULL)

On Aug 12, 2019, at 1:14 PM, Keith Medcalf wrote: > The only interesting thing is CVE-2015-7036, but I don't know if that was so > much an SQLite3 issue, as it was an issue in the use of the tokenizer by > Apple. In either case, Apple fixed their bugs and SQLite3 was hardened > against some

Re: [sqlite] Please increase the default for SQLITE_MAX_VARIABLE_NUMBER

On Feb 4, 2020, at 12:26 PM, Simon Slavin wrote: > > On 4 Feb 2020, at 7:13pm, Deon Brewis wrote: > >> WHERE x IN (?1,?2,?3,?4...,?1000 ) > > People really do this ? Sheesh. It's a pretty common pattern. Sure, queries that are likely to use very large IN groups ought to be using carray or