Analysis and possible solution to getting unexpected SQLITE_CANTOPEN
errors from sqlite3_step
In pagerSharedLock, there is a test for the journal file
acessability immediatly followed by an attempt to open it.
If the journal file goes away between these two actions, sqlite3OsOpen
will return
On 4 Oct 2010, at 10:52pm, Jay A. Kreibich wrote:
> For good or for bad, this is the behavior of both sqlite3_open() and
> sqlite3_open_v2(). I'm sure you'd see the same thing with all VFS
> modules.
>
> http://www.sqlite.org/c3ref/open.html
>
> It seems odd to me as well, especially
On Mon, Oct 04, 2010 at 02:40:45PM -0700, Dave Dyer scratched on the wall:
> (I'm a little curious about the logic in unixOpen, which if a
> read/write open fails, tries a readonly open instead. I'm unsure
> how this is supposed to be acceptable.
For good or for bad, this is the behavior of
I've collected a little more information about this problem.
At the low level sqlite3_step is going through "pagerSharedLock"
and ultimately to unixOpen, which is returning unix errno=2
for the journal file.
-- presumably at this point, the journal file is known to exist,
so error 2 ought to
I've collected a little more information about this problem.
At the low level sqlite3_step is going through "pagerSharedLock"
and ultimately to unixOpen, which is returning unix errno=2
for the journal file.
-- presumably at this point, the journal file is known to exist,
so error 2 ought to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/02/2010 02:01 PM, Dave Dyer wrote:
> Not trying to blame anyone here, just to gather information and ultimately
> find a reliable solution.
Your reliable solution is to not use networked filesystems with SQLite.
Alternatives are using a
On 2 Oct 2010, at 10:01pm, Dave Dyer wrote:
>> 2. If ignoring #1, prove that the network disk implementation is correct
>> before blaming SQLite.
>
> Not trying to blame anyone here, just to gather information and ultimately
> find a reliable solution.
No problem. It is unfortunate that most
>
>
> 2. If ignoring #1, prove that the network disk implementation is correct
>before blaming SQLite.
Not trying to blame anyone here, just to gather information and ultimately
find a reliable solution.
> 3. Watch out for other background tag-a-longs causing weird behaviour on
>Windows.
I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/02/2010 12:11 PM, Dave Dyer wrote:
> Neither of these fits the scenario, which is multiple readers
> contending for access to a networked disk.
See the second paragraph of http://www.sqlite.org/faq.html#q5
People have repeatedly found that
>
>If the previous process to access the database was in the middle of a write
>but crashed before the write could complete, then your "read-only" process
>will still need to write to the database in order to clean up the mess left
>behind by the prior process before it can start its query. So
>
>If the previous process to access the database was in the middle of a write
>but crashed before the write could complete, then your "read-only" process
>will still need to write to the database in order to clean up the mess left
>behind by the prior process before it can start its query. So
On Sat, Oct 2, 2010 at 4:35 AM, Dave Dyer wrote:
>
> Ok, I'll settle for a list of the errors that can be returned by
> the standard codebase, and particularly what SQLITE_CANTOPEN means
> when the database clearly was already open.
>
> Also, this is coming from a
Ok, I'll settle for a list of the errors that can be returned by
the standard codebase, and particularly what SQLITE_CANTOPEN means
when the database clearly was already open.
Also, this is coming from a SELECT query, so there should be no
question of opening a transaction file.
On Fri, Oct 1, 2010 at 6:24 PM, Wolfgang Enzinger wrote:
> Am Fri, 01 Oct 2010 14:11:51 -0700 schrieb Dave Dyer:
>
> > There ought to be a definitive list of what errors can occur
> > after sqlite3_step, and which (if any) are recoverable.
>
> IMHO that's impossible, at least
Am Fri, 01 Oct 2010 14:11:51 -0700 schrieb Dave Dyer:
> There ought to be a definitive list of what errors can occur
> after sqlite3_step, and which (if any) are recoverable.
IMHO that's impossible, at least because SQLite allows the definition of
user defined functions. Now such a function may
There ought to be a definitive list of what errors can occur
after sqlite3_step, and which (if any) are recoverable.
In the case in point, I sqlite_prepare_v2 returns sqlite_ok,
and the initial call to sqlite_step returns sqlite_cantopen
This doesn't make any sense to me, and certainly isn't
16 matches
Mail list logo