Thanks Dennis Cote. Now even though synchrounous is set to FULL. But Database
Corrouption is happening. Here are my observations in our sqlite 2.8.13.
1. This corrouption is not detected by the sqlite_open().
2. After the crash/power failure. I see a journal file in the same directory as
the d
jayanth KP wrote:
But how do we read the current synchronous value using C interface. Plz
reply.
Jayanth,
Try this:
sqlite3_stmt* s;
sqlite3_prepare(db, "PRAGMA SYNCHRONOUS", -1, &s, NULL);
sqlite3_step(s);
int sync = sqlite3_column_int(s, 1);
sqlite3_finalize(s);
s
Hi Dennis Cote,
But how do we read the current synchronous value using C interface. Plz
reply.
Regards
Jayanth
On Mon, 16 Oct 2006 Dennis Cote wrote :
>jayanth KP wrote:
>>Thanks for ur reply. I searched in the whole source code i could not find
>> SQLITE_NO_SYNC flag.
>>Also i tried
jayanth KP wrote:
Thanks for ur reply. I searched in the whole source code i could not find SQLITE_NO_SYNC flag.
Also i tried the following in my c code, after sqlite_open() was success.
sqlite_exec(pDbHandle,"PRAGMA synchronous=FULL;", NULL, NULL, &pErrMsg);
Even this did not seem to work.
Hi Richard,
Thanks for ur reply. I searched in the whole source code i could not find
SQLITE_NO_SYNC flag.
Also i tried the following in my c code, after sqlite_open() was success.
sqlite_exec(pDbHandle,"PRAGMA synchronous=FULL;", NULL, NULL, &pErrMsg);
Even this did not seem to work. How d
* jayanth KP:
>Please can anybody respond to this question. I am able to hits is
>issue pretty often now...
You should check that your operating system and hardware actually
flush buffers when told to do so. Here's a test you can run:
http://cvs.danga.com/browse.cgi/wcmtools/diskchecker
"jayanth KP" <[EMAIL PROTECTED]> wrote:
> Hi Richard,
>
> We are ALREADY using sqlite 2.8.13.
Your original post said you were using 2.8.3. Must have
been a typo.
>
> OBSERVATIONS:
> -
>
> 1) If i call sync() system call after database update, the database is not
> getting corrup
Hi Richard,
We are ALREADY using sqlite 2.8.13.
OBSERVATIONS:
-
1) If i call sync() system call after database update, the database is not
getting corrupted.
2) In one scenario of corruption sqlite_open() returned an error message "file
is encrypted or is not a database".
3) In a
"jayanth KP" <[EMAIL PROTECTED]> wrote:
> Hi,
>
>Please can anybody respond to this question. I am able to hits is issue
> pretty often now...
In my previous response, reproduced below, I showed you the
cause of the problem and how to fix it. What further response
do you want?
>
> > >
> >
Hi,
Please can anybody respond to this question. I am able to hits is issue
pretty often now...
Regards,
Jayanth
On Fri, 06 Oct 2006 [EMAIL PROTECTED] wrote :
>"jayanth KP" <[EMAIL PROTECTED]> wrote:
> > Hi,
> >I have a question regarding power failure handling in sqlite 2.8.3.
> >
Hi Richard,
Sorry, i gave a wrong version number of sqlite . We are using sqlite 2.8.13.
OBSERVATIONS:
-
1) If i call sync() system call after database update, the database is not
getting corrupted.
2) In one scenario of corruption sqlite_open() returned an error message "file
"jayanth KP" <[EMAIL PROTECTED]> wrote:
> Hi,
>I have a question regarding power failure handling in sqlite 2.8.3.
>
> When the power is switched off during a database write like (insert/update),
> in next reboot database is getting corroupted.
>
> The database is in a ext3 partition on t
Hi,
I have a question regarding power failure handling in sqlite 2.8.3.
When the power is switched off during a database write like (insert/update),
in next reboot database is getting corroupted.
The database is in a ext3 partition on the harddisk (linux 2.6).
Also i tried the followi
13 matches
Mail list logo