[sqlite] pragma temp_store_directory is deprecated, what is the alternative?

> On 15 Aug 2015, at 12:53am, James K. Lowden > wrote: > > Simon Slavin wrote: > ... >> If it's going to be documented, it would also be nice to see it on >> >> >> >> which, according to my browser, doesn't mention the word >> 'environment'. > > I

[sqlite] Using uninitialized value nDummy when calling vdbePmaReaderInit

Bug list return me error, so posting here hoping someone watchs it. A suspicious piece of code. The variable nDummy is not initialized *(1)* in the function but its pointer *(2)* is passed to *vdbePmaReaderInit* that increments *(3)* its value. static int vdbeMergeEngineLevel0( SortSubtask

[sqlite] Logically dead code in function sqlite3_index_info

Hi. This is a logically dead code because TERM_VNULL is 0. The 'continue' *(1)* will never be executed. testcase( pTerm->eOperator & WO_ISNULL ); testcase( pTerm->eOperator & WO_ALL ); if( (pTerm->eOperator & ~(WO_ISNULL|WO_EQUIV|WO_IS))==0 ) continue; if( pTerm->wtFlags &

[sqlite] Using uninitialized value nDummy when calling vdbePmaReaderInit

On 15 August 2015 at 14:35, Carlos Tangerino wrote: > > The variable nDummy is not initialized *(1)* in the function but its > pointer *(2)* is passed to *vdbePmaReaderInit* that increments *(3)* its > value. > nDummy is never used after vdbePmaReaderInit though, so it doesn't really matter that

[sqlite] Logically dead code in function sqlite3_index_info

On 8/15/15, Carlos Tangerino wrote: > Hi. > This is a logically dead code because TERM_VNULL is 0. VNULL can be 0 or 0x80, depending on your compile-time configuration. > The 'continue' *(1)* will never be executed. > > testcase( pTerm->eOperator & WO_ISNULL ); > testcase(

[sqlite] journal files not always removed

Hello, I've recently found SQLite doesn't always remove its journal files anymore. The issue seems to occur when opening WAL databases in read-only mode (i.e. using SQLITE_OPEN_READONLY). A scenario to reproduce this (using version 3.8.11.1) looks like: 1. open a WAL database in read-only

[sqlite] journal files not always removed

On 8/15/15, Ashwin Hirschi wrote: > > Hello, > > I've recently found SQLite doesn't always remove its journal files anymore. > > The issue seems to occur when opening WAL databases in read-only mode > (i.e. using SQLITE_OPEN_READONLY). > > A scenario to reproduce this (using version 3.8.11.1)

[sqlite] journal files not always removed

Checked this on WIndows 7 & 8, works as expected. This means either Windows 10 has some glitch or the access level to the folder is not correct, files may not be deleted by that process or some antivirus is checking the file while SQLite is trying to delete it, or you are not closing the DB

[sqlite] journal files not always removed

Also, make sure that folder is not a shared resource or inside a shared resource that is visible from any other network node or machine. This piece, describing the same symptom for Internet Explorer temporary files, may help: https://support.microsoft.com/en-us/kb/814782 What happens when you

[sqlite] journal files not always removed

>> I've recently found SQLite doesn't always remove its journal files >> anymore. >> >> The issue seems to occur when opening WAL databases in read-only mode >> (i.e. using SQLITE_OPEN_READONLY). >> >> A scenario to reproduce this (using version 3.8.11.1) looks like: >> >> 1. open a WAL

[sqlite] journal files not always removed

> Also, make sure that folder is not a shared resource or inside a shared > resource that is visible from any other network node or machine. > > This piece, describing the same symptom for Internet Explorer temporary > files, may help: > https://support.microsoft.com/en-us/kb/814782 The

[sqlite] journal files not always removed

This is something changed in SQLITE itself. These tests are on Windows 10 using the current MinGW compiler with the same configuration and windows headers. For the current head of trunk: 2015-08-15 12:17:05 [D:\Temp] >type test.sql pragma journal_mode=wal; pragma journal_mode; create table

[sqlite] journal files not always removed

On 8/15/15, Keith Medcalf wrote: > > This is something changed in SQLITE itself. These tests are on Windows 10 > using the current MinGW compiler with the same configuration and windows > headers. > Do you also have MSYS installed? If so can you run the following shell script and see if it

[sqlite] journal files not always removed

Quite Fascinating! Here is the transcript (it is running the Windows SQLITE.EXE which I have in a different location in the path, so slightly modified the script): KMedcalf at WYNPCLLT3 ~ $ rm -rf t1.db* KMedcalf at WYNPCLLT3 ~ $ sqlite t1.db <<\EOF > PRAGMA journal_mode=WAL; > CREATE TABLE

[sqlite] journal files not always removed

On 8/15/15, Keith Medcalf wrote: > > Quite Fascinating! Here is the transcript (it is running the Windows > SQLITE.EXE which I have in a different location in the path, so slightly > modified the script): > Ugh. There is a bug in my script. The final "ls -l" should have a "*" at the end

[sqlite] journal files not always removed

> With this new test case, I see that the -shm and -wal files are > retained upon exit in read-only mode. Great. Good to see other people are able to reproduce (some? of) the issue. > But I also see that behavior dates back to 3.7.6 and maybe earlier. It > isn't something new. > (Testing on

[sqlite] journal files not always removed

On 8/15/15, Ashwin Hirschi wrote: > >> But I also see that behavior dates back to 3.7.6 and maybe earlier. It >> isn't something new. >> (Testing on Ubuntu). > > Also, are you sure you testing things right? I thought URI support was > only added in 3.7.7... If that's true, your little script