On 28 Jun 2016, at 4:24pm, mon siong wrote:
> Yes , I always do this check before i proceed next step . if(rc !=
> SQLITE_OK){ }
Very good.
> I just crash my database with 1 thread keep reading , another thread keep
> inserting . Here is how i open the DB connection .
Yes , I always do this check before i proceed next step . if(rc != SQLITE_OK){
}
I just crash my database with 1 thread keep reading , another thread keep
inserting . Here is how i open the DB connection .
rc = sqlite3_open_v2(DEFAULT_FAILTS_DB,
Sorry, that should read
> All API calls should return SQLITE_OK except for sqlite_step() which can
> return SQLITE_ROW or SQLITE_DONE too. Any other code indicates a fault and
> your program
... should crash ...
> when it sees them, before more harm is done.
Simon.
On 27 Jun 2016, at 3:53pm, mon siong wrote:
> I intend to do error log callback . I want to terminate my program when an
> operation could potentially cause my DB to corrupt to identify which code
> actually cause this .
>
> Which Result code that i need to capture
All
Thanks Simon . I intend to do error log callback . I want to terminate my
program when an operation could potentially cause my DB to corrupt to identify
which code actually cause this .
Which Result code that i need to capture which could potentially cause my DB to
corrupt ?
SQLite Result
On 26 Jun 2016, at 4:11pm, mon siong wrote:
> Open the database without close can cause DB corrupt ?
Not if the software and hardware is working correctly. The next time you open
the database SQLite will work out that it wasn't closed correctly and will
Hi Scott
Open the database without close can cause DB corrupt ?
On Friday, June 24, 2016 12:24 PM, Scott Robison
wrote:
On Thu, Jun 23, 2016 at 7:47 PM, mon siong wrote:
> Thanks I will try internal hard drive. This is not
On Thu, Jun 23, 2016 at 7:47 PM, mon siong wrote:
> Thanks I will try internal hard drive. This is not virtual machine , my
> application is running on linux ARM .
>
> 1) Make sure I need to check SQLITE_OK before i proceed to perform next
> task 2) Move the sqlite file to
Thanks I will try internal hard drive. This is not virtual machine , my
application is running on linux ARM .
1) Make sure I need to check SQLITE_OK before i proceed to perform next task 2)
Move the sqlite file to Internal hard drive
2) Add sqlite_3_config error log callback to find out which
On Thu, Jun 23, 2016 at 11:08 AM, mon siong wrote:
>
> You have idea why the journal and shm file is corrupt ?
>
My first thought was a remote file system. My next instinct is to suspect
the USB device or interface is suspect. Can you try it on an internal hard
drive? Is
You have idea why the journal and shm file is corrupt ?
From the previous Thread
(http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2016-January/063830.html),
you mention to use showdb to check the DB corrupt . Where to download the
showdb program ?
On Thursday,
Both processes on a single computer accessing a local file system. The sqlite
file is store in USB drive , and I notice if the database corrupt , the journal
or shm file is also corrupt .
On Thursday, June 23, 2016 12:48 PM, Scott Robison
wrote:
On Jun
On Jun 22, 2016 9:25 PM, "mon siong" wrote:
>
>
> PHP use 3.7.7.1 and my c program use 3.8.4.3 . Different version of
sqlite is fine ?
> I tried WAL and Delete Journal Mode , both type cause the db to corrupt .
>
> Under which scenario, two different global variables will be
On Wed, Jun 22, 2016 at 8:13 PM, Simon Slavin wrote:
> On 23 Jun 2016, at 3:52am, mon siong wrote:
>> PHP is using sqlite3 library (http://php.net/manual/en/book.sqlite3.php)
>> and C program is handle the sqlite using Serialized.
>>
>> Both of them are
PHP use 3.7.7.1 and my c program use 3.8.4.3 . Different version of sqlite is
fine ?
I tried WAL and Delete Journal Mode , both type cause the db to corrupt .
Under which scenario, two different global variables will be used ?
On Thursday, June 23, 2016 11:13 AM, Simon Slavin
On 23 Jun 2016, at 3:52am, mon siong wrote:
> PHP is using sqlite3 library (http://php.net/manual/en/book.sqlite3.php)
> and C program is handle the sqlite using Serialized.
>
> Both of them are accessing the same DB at the same time . This can cause DB
> corrupt ?
No.
Hello
My sqlite database corrupt recently, I suspecting this is due to the two
different instances of SQLIte running on unix . And two different global
variables is used .
(By refering to the thread:
http://mailinglists.sqlite.org/cgi-bin/mailman/private/sqlite-users/2016-May/066648.html)
We
try
my best to do it. :)
???:Simon Slavinslavins at bigfraud.org
???:SQLite mailing listsqlite-users at mailinglists.sqlite.org
:2016?1?14?(??)?20:39
??:Re: [sqlite] Database Corrupt While Disk Full
On 14 Jan 2016, at 11:55am, Brice Andr? brice.andre at ams-solutions.be wrote:
I
] Database Corrupt While Disk Full
On 14 Jan 2016, at 9:58am, sanhua.zh sanhua.zh at foxmail.com wrote: Through
the error code timeline, it shows that much of SQLITE_FULL, SQLITE_IOERR,
SQLITE_CANTOPEN happened before SQLITE_CORRUPT. You should never get to this
situation. The three result codes
On 2016/01/14 6:46 PM, R Smith wrote:
> ...// Out-of-memory and out-of-diskspace type errors are reported//
Also note here that there is a case where SQLite will report DISK_FULL
errors where the disks are seemingly fine - when you start a transaction
that requires large amounts of space,
On 2016/01/14 3:02 PM, sanhua.zh wrote:
> 1. Not all other codes except SQLITE_OK, SQLITE_ROW, SQLITE_DONE should be
> treated as fatal errors.
>As an example, SQLITE_BUSY indicates that this op is temporarily failed,
> but it can be done later. (Note that sometimes you should not retry
the database. Can you teach me a little
more in detail ? I haven?t found the relative code in SQLite source code.
???:Simon Slavinslavins at bigfraud.org
???:SQLite mailing listsqlite-users at mailinglists.sqlite.org
:2016?1?14?(??)?17:46
??:Re: [sqlite] Database Corrupt While Disk Full
Recently, my monitoring system showed that the error code SQLITE_FULL and
SQLITE_CORRUPT increasing in same trend. And thousands of users, who?s database
is corrupt, also traped inlow disk free space and their log show that
SQLITE_IOERR, SQLITE_FULL happenedsimultaneously.
I confuse that
On Thu, Jan 14, 2016 at 2:09 PM, Stephan Beal wrote:
> FULL means the drive is full. Most apps can't do much about that. It
> generally needs to be resolved by user action - freeing up space.
>
Alternately, FULL can mean that the current VFS cannot allocate space, even
though it's underlying
On Thu, Jan 14, 2016 at 2:02 PM, sanhua.zh wrote:
> I don?t mean to be rude. BUT, I can?t agree with your opinion, Simon.
>
>
> 1. Not all other codes except SQLITE_OK, SQLITE_ROW, SQLITE_DONE should be
> treated as fatal errors.
> As an example, SQLITE_BUSY indicates that this op is
On 14 Jan 2016, at 1:02pm, sanhua.zh wrote:
> I don?t mean to be rude. BUT, I can?t agree with your opinion, Simon.
I will present some arguments on my side. I hope you take this as cultured
conversation and not an outright rejection of your points.
> 1. Not all other codes except
Dear Simon,
I am a little worried with your last post because, I must admint that I do
not take special measures in my application when such errors occur to
guarantee that no more DB access are performed.
I have thus the following questions :
1. What would be the proper reaction to
> On 14 Jan 2016, at 11:55am, Brice Andr?
> wrote:
>
> I am a little worried with your last post because, I must admint that I do
> not take special measures in my application when such errors occur to
> guarantee that no more DB access are performed.
>
> I have thus the following questions :
On Thu, Jan 14, 2016 at 10:58 AM, sanhua.zh wrote:
> Through the error code timeline, it shows that much of SQLITE_FULL,
> SQLITE_IOERR, SQLITE_CANTOPEN happened before SQLITE_CORRUPT. Database
> might be in an obscure state while disk is full, then it corrupt in some
> unknown reason.
>
>
> As
On 14 Jan 2016, at 9:58am, sanhua.zh wrote:
> Through the error code timeline, it shows that much of SQLITE_FULL,
> SQLITE_IOERR, SQLITE_CANTOPEN happened before SQLITE_CORRUPT.
You should never get to this situation. The three result codes SQLITE_FULL,
SQLITE_IOERR, SQLITE_CANTOPEN are
On 14 Jan 2016, at 8:44am, sanhua.zh wrote:
> Recently, my monitoring system showed that the error code SQLITE_FULL and
> SQLITE_CORRUPT increasing in same trend. And thousands of users, who?s
> database is corrupt, also traped inlow disk free space and their log show
> that SQLITE_IOERR,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 14/01/16 00:44, sanhua.zh wrote:
> Recently, my monitoring system showed that the error code
> SQLITE_FULL and SQLITE_CORRUPT increasing in same trend.
Just as another data point, I had SQLite using code in a library that
was used across a bunch
Thanks Simon!
We also store our critical data synchronously in flat (csv) files before
sending it in the sqlite database. When the hard reboot occured only one
of these was corrupted and only the last line.
We can always refill sqlite from these files, we use sqlite to allow us
to easily offer
On 22 Oct 2015, at 11:16am, gunnar wrote:
> It's good to know there are so many possibilities to repair when it is really
> needed!
But it's worth noting that these are only possibilities. There is no guarentee
of repair. And trying out one possibility can corrupt your database further so
Hi Paul, thanks!
It's good to know there are so many possibilities to repair when it is
really needed!
On 10/19/2015 10:21 PM, Paul Sanderson wrote:
> Gunnar
>
> If the data is very important then don't do anything that will change
> the computer.
>
> If you have sometools that can take an
Gunnar
If the data is very important then don't do anything that will change
the computer.
If you have sometools that can take an image copy of the disk (DD to
another drive) or maybe the free accessdata imaging software then I
would recommend doing this first - it will leave all options open
Thanks a lot Simon!
We'll try it.
(BTW I also got an email from alexa, but looking in the sqlite mailing
list I can see that I'm not the only one)
On 10/19/2015 06:20 PM, Simon Slavin wrote:
> On 19 Oct 2015, at 5:13pm, gunnar wrote:
>
>> We run sqlite with PRAGMA synchronous=OFF.
>>
>> Now
Hi,
We run sqlite with PRAGMA synchronous=OFF.
Now we suffered from a 'hard reboot' because a sysadmin unplugged the
power cable :(
Is it possible to repair when you see after that:
OrderCallbackStorage::checkDatabaseIntegrity: row 1 [*** in database
main ***
On tree page 413956 cell 2:
On 19 Oct 2015, at 5:13pm, gunnar wrote:
> We run sqlite with PRAGMA synchronous=OFF.
>
> Now we suffered from a 'hard reboot' because a sysadmin unplugged the power
> cable :(
>
> Is it possible to repair
First take a copy of the database file and any other file from the same
directory
On Wed, 15 Jul 2009 08:29:15 +0200, Denis Gottardello
wrote:
>I have many cases of database corruption.
>May depend on what?
It shouldn't happen if you use it correctly.
This page is worth reading:
http://www.sqlite.org/atomiccommit.html
Please tell us the
I have many cases of database corruption. May depend on what? Someone using
sqlite in multi thread environment?
--
Denis Gottardello
Sintesi S.r.l.
___
sqlite-users mailing list
sqlite-users@sqlite.org
41 matches
Mail list logo