Re: [sqlite] sqlite Commit C API
On 21 May 2012, at 12:22pm, "Black, Michael (IS)" wrote: > I'll have to check the BIOS settings on my box and see if turning off write > caching makes more sense on that particular test. That won't do any harm, but you should be aware that your hardware lies. Some current hard disk drives don't even have jumper settings for 'write before acknowledge'. They just acknowledge the write command as soon as it's interpreted and do the physical write-to-surface when convenient, sometimes writing out-of-order because they save up writes and do them as the appropriate sector is rotated to the read/write head. In other words your hard disk drive lies to your computer, and there's nothing you can do about it. More expensive drives have jumper settings to put them in 'write before acknowledge' mode. And most of those actually implement it correctly. But you're very unlikely to find an internal boot disk in a computer set up like that because it slows the computer down a lot. Using something like Word, for instance, is annoyingly slow. You are more likely to see those jumper settings for a disk in a RAID frame, or an external hard disk drive used for archiving. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
Oh, duh!!! Thanks for the correction...brain gasbut what's an order of magnitude or two between friends? My current project has everything in per/sec so my mind was stuck in that mode. I'll have to check the BIOS settings on my box and see if turning off write caching makes more sense on that particular test. Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Igor Tandetnik [itandet...@mvps.org] Sent: Sunday, May 20, 2012 8:47 AM To: sqlite-users@sqlite.org Subject: EXT :Re: [sqlite] sqlite Commit C API Black, Michael (IS) wrote: > Hmmm...our math is a bit different... > > A 1,000 RPM disk would take 1ms to spin around once No it wouldn't. > (there are 1000ms in a second, correct?) Yes, but RPM stands for a revolution-per-*minute*. You are off by a factor of 60. -- Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On Sun, May 20, 2012 at 01:26:48PM +, Black, Michael (IS) scratched on the wall: > Hmmm...our math is a bit different... Yeah, your math is wrong... 8-) > A 1,000 RPM disk would take 1ms to spin around once A 1,000 RPS disk would, but not a 1,000 RPM disk. > I believe my original point stands...if your fsync() does nothing > you'll see something close to zero all the time. Agreed. I only meant to point out that when we're taking about physical I/O and spinning disks, "something close to zero" is measured in milliseconds, not fractions of a millisecond. If the OS is attempting to do the right thing, but the disk controller is lying about flushing the hardware cache, then you're likely to see something on the order of a millisecond or two. In that case you need to communicate all the way out to the storage device, but it isn't doing anything. If you're actually writing data to a spinning disk, I would expect times to be varied, and average out to slightly more than half a rotation. And rotations still take a LONG time in modern computing terms. -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
Black, Michael (IS) wrote: > Hmmm...our math is a bit different... > > A 1,000 RPM disk would take 1ms to spin around once No it wouldn't. > (there are 1000ms in a second, correct?) Yes, but RPM stands for a revolution-per-*minute*. You are off by a factor of 60. -- Igor Tandetnik ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
Hmmm...our math is a bit different... A 1,000 RPM disk would take 1ms to spin around once (there are 1000ms in a second, correct?) 10,000 RPM would take .1ms. 7200 RPM would take .138ms And...if I reduce the buffer size to 1 byte I see this...around 2-3X of rotation time with the sleep enabled. fsync time: 0.00040 fsync time: 0.00033 fsync time: 0.00028 fsync time: 0.00027 fsync time: 0.00027 fsync time: 0.00058 fsync time: 0.00032 fsync time: 0.00042 fsync time: 0.00029 fsync time: 0.00035 fsync time: 0.00033 fsync time: 0.00030 fsync time: 0.00027 fsync time: 0.00027 Remove the sleep though and the times drop to .04ms which indicates the my fsync() is probably write cached. I'm a telecommuter so I can't check the BIOS settings on this particular boxbut I'll bet it's write cached. I believe my original point stands...if your fsync() does nothing you'll see something close to zero all the time. Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] on behalf of Jay A. Kreibich [j...@kreibi.ch] Sent: Sunday, May 20, 2012 7:53 AM To: General Discussion of SQLite Database Subject: EXT :Re: [sqlite] sqlite Commit C API On Sun, May 20, 2012 at 12:04:33PM +, Black, Michael (IS) scratched on the wall: > Another more indirect way to test is this utility: > > http://kerneltrap.org/mailarchive/linux-ext4/2009/3/22/5215824 > > Which...if your fsync doesn't work at all will return something really > close to zero. > > On my RedHat system I get this which indicates fsync actually takes a > little of time...therefore it must be doing somethingalthough it > doesn't prove that it's actually on the disk yet. > > fsync time: 0.0022 > fsync time: 0.0019 > fsync time: 0.0019 > fsync time: 0.0022 > fsync time: 0.0019 > fsync time: 0.0019 > fsync time: 0.0020 > fsync time: 0.0020 Assuming this is spinning disk, that takes a *very* little amount of time... A 10K RPM disk takes about 6 ms to spin around once. A more conventional 7600 RPM drive takes 7.9 ms. Ignoring seek times, device I/O times, and all the rest, it should still take, on average, about half those times just for the right sector to come around underneath the heads. But that's just an average-- it should vary from write to write. I doubt sleep() is accurate enough to keep the program in sync with the spindle rotation over a full second. That doesn't seem to match the consistent, 2 ms times you're seeing. Both the low time, and the consistency of them, make me suspect of these numbers-- unless it is an SSD device. > And I do believe if you take the sleep() out of the loop that you should > see constant times. I would suspect that loop is faster than a disk rotation, so assuming there isn't much other I/O going on in the system, I would also expect to see somewhat more consistent times without the sleep(). > Otherwise you'll see a much bigger time once in a > while when you overrun the buffers and it has to pause to really flush. > > Again...on my system I see this...one value 3 times as large as the > others...suspicious. Yes... but not so much that one number is larger, as the fact that all the other numbers are consistently small. Of course, you can also see large changes in fsync() times if anything else on the system needs to do I/O. Again, assuming we're talking about spinning disk, if you have random I/O from other processes, you're going to see seeks and random rotation delays that should be even larger than this. -j > sort fsync.dat | tail -n 5 > fsync time: 0.0025 > fsync time: 0.0025 > fsync time: 0.0026 > fsync time: 0.0027 > fsync time: 0.0059 > -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On Sun, May 20, 2012 at 12:04:33PM +, Black, Michael (IS) scratched on the wall: > Another more indirect way to test is this utility: > > http://kerneltrap.org/mailarchive/linux-ext4/2009/3/22/5215824 > > Which...if your fsync doesn't work at all will return something really > close to zero. > > On my RedHat system I get this which indicates fsync actually takes a > little of time...therefore it must be doing somethingalthough it > doesn't prove that it's actually on the disk yet. > > fsync time: 0.0022 > fsync time: 0.0019 > fsync time: 0.0019 > fsync time: 0.0022 > fsync time: 0.0019 > fsync time: 0.0019 > fsync time: 0.0020 > fsync time: 0.0020 Assuming this is spinning disk, that takes a *very* little amount of time... A 10K RPM disk takes about 6 ms to spin around once. A more conventional 7600 RPM drive takes 7.9 ms. Ignoring seek times, device I/O times, and all the rest, it should still take, on average, about half those times just for the right sector to come around underneath the heads. But that's just an average-- it should vary from write to write. I doubt sleep() is accurate enough to keep the program in sync with the spindle rotation over a full second. That doesn't seem to match the consistent, 2 ms times you're seeing. Both the low time, and the consistency of them, make me suspect of these numbers-- unless it is an SSD device. > And I do believe if you take the sleep() out of the loop that you should > see constant times. I would suspect that loop is faster than a disk rotation, so assuming there isn't much other I/O going on in the system, I would also expect to see somewhat more consistent times without the sleep(). > Otherwise you'll see a much bigger time once in a > while when you overrun the buffers and it has to pause to really flush. > > Again...on my system I see this...one value 3 times as large as the > others...suspicious. Yes... but not so much that one number is larger, as the fact that all the other numbers are consistently small. Of course, you can also see large changes in fsync() times if anything else on the system needs to do I/O. Again, assuming we're talking about spinning disk, if you have random I/O from other processes, you're going to see seeks and random rotation delays that should be even larger than this. -j > sort fsync.dat | tail -n 5 > fsync time: 0.0025 > fsync time: 0.0025 > fsync time: 0.0026 > fsync time: 0.0027 > fsync time: 0.0059 > -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
If you can run perl on your ARM host try this utility to see if fsync() actually works -- this is a real end-to-end test that you pull the plug on and it will let you know if your disk file is where it's supposed to be and how many errors you had. http://brad.livejournal.com/2116715.html Another more indirect way to test is this utility: http://kerneltrap.org/mailarchive/linux-ext4/2009/3/22/5215824 Which...if your fsync doesn't work at all will return something really close to zero. On my RedHat system I get this which indicates fsync actually takes a little of time...therefore it must be doing somethingalthough it doesn't prove that it's actually on the disk yet. fsync time: 0.0022 fsync time: 0.0019 fsync time: 0.0019 fsync time: 0.0022 fsync time: 0.0019 fsync time: 0.0019 fsync time: 0.0020 fsync time: 0.0020 And I do believe if you take the sleep() out of the loop that you should see constant times. Otherwise you'll see a much bigger time once in a while when you overrun the buffers and it has to pause to really flush. Again...on my system I see this...one value 3 times as large as the others...suspicious. sort fsync.dat | tail -n 5 fsync time: 0.0025 fsync time: 0.0025 fsync time: 0.0026 fsync time: 0.0027 fsync time: 0.0059 Michael D. Black Senior Scientist Advanced Analytics Directorate Advanced GEOINT Solutions Operating Unit Northrop Grumman Information Systems ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
> On Thu, May 17, 2012 at 7:04 PM, Rajesh Kumar wrote:
>
int fsync( int fd ) { return 0; }
>
> fsync will expect an Integer pointer right. But sqlite pointer is of type
> sqlite3*. So how can fsync works on sqlite. What should I pass to fsync???
>
>
You don't need to call fsync(). Sqlite calls it internally to make sure no
corruption occurs. If it is broken on your system, then by extension any
software that depends on it working properly (such as sqlite) will be
broken, too.
--
˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On Thu, May 17, 2012 at 04:47:29PM +0100, Simon Slavin wrote:
>
> On 17 May 2012, at 4:34pm, Rajesh Kumar wrote:
>
> > No am not using any PRAGMAs. I just cross compiled sqlite source to
> > ARM architecture. Can't I forcefully do commit on my transaction
>
> If you are correctly using _open() and _close(), and haven't disabled
> synchrony with PRAGMAs or compilation settings, then you should be getting
> COMMIT automatically. There's no way to force SQLite to flush changes to
> disk because SQLite flushes changes to disk as part of normal working.
>
> As for use of COMMIT ? every SQL command executed with SQLite is part of a
> transaction. So normal programming tends to look like
>
> BEGIN;
> ? any number of INSERT, DELETE, SELECT, UPDATE commands here ?
> COMMIT;
>
> By the time SQLite has returned from the COMMIT, your changes should have
> made it to disk. There's no flushing to do, SQLite already did it.
>
> If you do happen to issue a SQL command without having issued a 'BEGIN'
> first, then SQLite helpfully wraps it in its own transaction for you,
> executing all of these
>
> BEGIN (<-- I helpfully do this for you because you forgot)
> Your command here
> COMMIT (<-- since you forgot the BEGIN you'll probably forget the COMMIT too)
>
> with the single call to sqlite3_exec() you made, and doing the COMMIT before
> it returns from processing that call. So even if all you do is use
> sqlite3_exec('UPDATE command here'), SQLite has already done all the flushing
> to disk that needs doing.
>
> However, the code in SQLite that does the COMMIT includes the C command
> fsync() as part of its working. (I think this is right. I haven't read the
> source code.) And its the fsync() that does the flushing. So if that's not
> correctly implemented on your platform (which is depressingly common) then
> things like application crashes or power loss can lead to a corrupt database.
> Which is why Richard pointed to
>
> http://www.sqlite.org/atomiccommit.html and
> http://www.sqlite.org/howtocorrupt.html
>
Note, also, if you do a BEGIN, but don't get as far as a COMMIT before
losing power, sqlite *should* be able to recover without corrupting
the database if fsync() is working, as it saves recovery information
on the fly.
BTW, what embedded OS are you using? Perhaps check with the vendor on
their fsync() implementation?
Christian
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
Funny!
But, very inefficient. Suggest:
#define fsync(x)
Marc
-Original Message-
From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.org]
On Behalf Of Simon Slavin
Sent: Thursday, May 17, 2012 11:52 AM
To: j...@kreibi.ch; General Discussion of SQLite Database
Subject: Re: [sqlite] sqlite Commit C API
On 17 May 2012, at 4:49pm, Jay A. Kreibich wrote:
> I wouldn't be all that shocked to find out an embedded system has an
> fsync() call that looks like this:
>
> int fsync( int fd ) { return 0; }
We are best software circle ! Our programmers write many functions a day !
Our functions run fastest ! Our functions never give errors ! Buy us products
now !
Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On 17 May 2012, at 5:04pm, Rajesh Kumar wrote:
> int fsync( int fd ) { return 0; }
>
> fsync will expect an Integer pointer right. But sqlite pointer is of type
> sqlite3*. So how can fsync works on sqlite. What should I pass to fsync???
Sorry Rajesh. It was a programmer's joke. Ignore that.
Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
int fsync( int fd ) { return 0; }
fsync will expect an Integer pointer right. But sqlite pointer is of type
sqlite3*. So how can fsync works on sqlite. What should I pass to fsync???
On Thu, May 17, 2012 at 9:19 PM, Jay A. Kreibich wrote:
> int fsync( int fd ) { return 0; }
--
*
Thanks & Regards,
Rajesh Kumar P
*
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On 17 May 2012, at 4:49pm, Jay A. Kreibich wrote:
> I wouldn't be all that shocked to find out an embedded system has an
> fsync() call that looks like this:
>
> int fsync( int fd ) { return 0; }
We are best software circle ! Our programmers write many functions a day !
Our functions run fastest ! Our functions never give errors ! Buy us products
now !
Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On Thu, May 17, 2012 at 08:58:39PM +0530, Rajesh Kumar scratched on the wall:
> Hi Richard,
>
> Thanks for the reply. fsync() is related to system call, which is
> working fine.
I believe you're missing Richard's point. I'm sure fsync() is
returning a success error code. That doesn't mean it is working
correctly. fsync() is a hardware call that dives deep, deep into the
OS, hardware, and even storage sub-system of your device. All of
those items need to function correctly for the return code of fsync()
to actually mean anything.
As the URL provided points out, many commercial hard drives and
storage systems, designed for desktops and server systems, get this
wrong-- or flat out lie about it. If the hardware lies about what's
going on, there is nothing the OS-- or SQLite-- can do about it. Nor
is there anything an additional API call is going to fix.
I wouldn't be all that shocked to find out an embedded system has an
fsync() call that looks like this:
int fsync( int fd ) { return 0; }
> But I am looking for a C API that can do the commit thing,
> which is same as commit on command promt.
There isn't one. But even if there was, it wouldn't work any
differently, or any better. It wouldn't fix the corruption issues
you're seeing.
-j
> On Thu, May 17, 2012 at 8:52 PM, Richard Hipp wrote:
>
> > On Thu, May 17, 2012 at 11:18 AM, Rajesh Kumar
> > wrote:
> >
> > > Hi all,
> > >
> > >Am using sqlite database on my ARM processor based Embedded system .
> > > Whenever power failures or due to uneven shutdown of device, my database
> > > is being corrupted which leading to data lost.
> >
> >
> > That should never happen. It suggests that fsync() is not working on your
> > OS. Further information: http://www.sqlite.org/atomiccommit.html and
> > http://www.sqlite.org/howtocorrupt.html
> >
> >
> >
> > > Am using C API interface for
> > > accessing database. Is there any C API that I can use to commit my DB
> > > manually. I know sqlite has own auto commit mechanism but it's not
> > working
> > > for me.
> > >
> > > Thanks in advance.
> > >
> > > --
> > > *
> > > Thanks & Regards,
> > > Rajesh Kumar P
> > > *
> > > ___
> > > sqlite-users mailing list
> > > sqlite-users@sqlite.org
> > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> > >
> >
> >
> >
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> > ___
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
>
>
>
> --
> *
> Thanks & Regards,
> Rajesh Kumar P
> *
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
--
Jay A. Kreibich < J A Y @ K R E I B I.C H >
"Intelligence is like underwear: it is important that you have it,
but showing it to the wrong people has the tendency to make them
feel uncomfortable." -- Angela Johnson
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On 17 May 2012, at 4:34pm, Rajesh Kumar wrote:
> No am not using any PRAGMAs. I just cross compiled sqlite source to
> ARM architecture. Can't I forcefully do commit on my transaction
If you are correctly using _open() and _close(), and haven't disabled synchrony
with PRAGMAs or compilation settings, then you should be getting COMMIT
automatically. There's no way to force SQLite to flush changes to disk because
SQLite flushes changes to disk as part of normal working.
As for use of COMMIT … every SQL command executed with SQLite is part of a
transaction. So normal programming tends to look like
BEGIN;
… any number of INSERT, DELETE, SELECT, UPDATE commands here …
COMMIT;
By the time SQLite has returned from the COMMIT, your changes should have made
it to disk. There's no flushing to do, SQLite already did it.
If you do happen to issue a SQL command without having issued a 'BEGIN' first,
then SQLite helpfully wraps it in its own transaction for you, executing all of
these
BEGIN (<-- I helpfully do this for you because you forgot)
Your command here
COMMIT (<-- since you forgot the BEGIN you'll probably forget the COMMIT too)
with the single call to sqlite3_exec() you made, and doing the COMMIT before it
returns from processing that call. So even if all you do is use
sqlite3_exec('UPDATE command here'), SQLite has already done all the flushing
to disk that needs doing.
However, the code in SQLite that does the COMMIT includes the C command fsync()
as part of its working. (I think this is right. I haven't read the source
code.) And its the fsync() that does the flushing. So if that's not correctly
implemented on your platform (which is depressingly common) then things like
application crashes or power loss can lead to a corrupt database. Which is why
Richard pointed to
http://www.sqlite.org/atomiccommit.html and
http://www.sqlite.org/howtocorrupt.html
Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
So if I use _exec() after sqlit3_exec() API, what ever the I did on database will be saved, right?? On Thu, May 17, 2012 at 9:03 PM, Simon Slavin wrote: > > On 17 May 2012, at 4:28pm, Rajesh Kumar wrote: > > >Thanks for the reply. fsync() is related to system call, which is > > working fine. But I am looking for a C API that can do the commit thing, > > which is same as commit on command promt. > > > The COMMIT; on a command prompt does the same thing as executing 'COMMIT' > as a SQL call. Just use _exec() to do a 'COMMIT' and you'll get the same > results. If the shell tool works because it uses COMMIT, then your own app > will work because it uses COMMIT too. > > But what the other guys are saying is COMMIT depends on fsync() working, > and fsync() is broken on some platforms. And if COMMIT can't depend on > fsync() then it can't do its job. > > Simon. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- * Thanks & Regards, Rajesh Kumar P * ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
No am not using any PRAGMAs. I just cross compiled sqlite source to ARM architecture. Can't I forcefully do commit on my transaction On Thu, May 17, 2012 at 8:55 PM, Simon Slavin wrote: > > On 17 May 2012, at 4:18pm, Rajesh Kumar wrote: > > > Am using sqlite database on my ARM processor based Embedded system . > > Whenever power failures or due to uneven shutdown of device, my database > > is being corrupted which leading to data lost. Am using C API interface > for > > accessing database. > > Are you using any PRAGMAs ? > > Have you compiled your own version with SQLite directives which might be > disabling sync ? > > Simon. > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- * Thanks & Regards, Rajesh Kumar P * ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On 17 May 2012, at 4:28pm, Rajesh Kumar wrote: >Thanks for the reply. fsync() is related to system call, which is > working fine. But I am looking for a C API that can do the commit thing, > which is same as commit on command promt. The COMMIT; on a command prompt does the same thing as executing 'COMMIT' as a SQL call. Just use _exec() to do a 'COMMIT' and you'll get the same results. If the shell tool works because it uses COMMIT, then your own app will work because it uses COMMIT too. But what the other guys are saying is COMMIT depends on fsync() working, and fsync() is broken on some platforms. And if COMMIT can't depend on fsync() then it can't do its job. Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
Hi Richard, Thanks for the reply. fsync() is related to system call, which is working fine. But I am looking for a C API that can do the commit thing, which is same as commit on command promt. On Thu, May 17, 2012 at 8:52 PM, Richard Hipp wrote: > On Thu, May 17, 2012 at 11:18 AM, Rajesh Kumar > wrote: > > > Hi all, > > > >Am using sqlite database on my ARM processor based Embedded system . > > Whenever power failures or due to uneven shutdown of device, my database > > is being corrupted which leading to data lost. > > > That should never happen. It suggests that fsync() is not working on your > OS. Further information: http://www.sqlite.org/atomiccommit.html and > http://www.sqlite.org/howtocorrupt.html > > > > > Am using C API interface for > > accessing database. Is there any C API that I can use to commit my DB > > manually. I know sqlite has own auto commit mechanism but it's not > working > > for me. > > > > Thanks in advance. > > > > -- > > * > > Thanks & Regards, > > Rajesh Kumar P > > * > > ___ > > sqlite-users mailing list > > sqlite-users@sqlite.org > > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > > > > > > -- > D. Richard Hipp > d...@sqlite.org > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- * Thanks & Regards, Rajesh Kumar P * ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On Thu, May 17, 2012 at 11:22:44AM -0400, Richard Hipp scratched on the wall: > On Thu, May 17, 2012 at 11:18 AM, Rajesh Kumar wrote: > > > Hi all, > > > >Am using sqlite database on my ARM processor based Embedded system . > > Whenever power failures or due to uneven shutdown of device, my database > > is being corrupted which leading to data lost. > > > That should never happen. It suggests that fsync() is not working on your > OS. Further information: http://www.sqlite.org/atomiccommit.html and > http://www.sqlite.org/howtocorrupt.html ...which means any "manual" API call to force a sync is also likely to be broken and not work correctly. -j > > Am using C API interface for > > accessing database. Is there any C API that I can use to commit my DB > > manually. I know sqlite has own auto commit mechanism but it's not working > > for me. -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On 17 May 2012, at 4:18pm, Rajesh Kumar wrote: > Am using sqlite database on my ARM processor based Embedded system . > Whenever power failures or due to uneven shutdown of device, my database > is being corrupted which leading to data lost. Am using C API interface for > accessing database. Are you using any PRAGMAs ? Have you compiled your own version with SQLite directives which might be disabling sync ? Simon. ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] sqlite Commit C API
On Thu, May 17, 2012 at 11:18 AM, Rajesh Kumar wrote: > Hi all, > >Am using sqlite database on my ARM processor based Embedded system . > Whenever power failures or due to uneven shutdown of device, my database > is being corrupted which leading to data lost. That should never happen. It suggests that fsync() is not working on your OS. Further information: http://www.sqlite.org/atomiccommit.html and http://www.sqlite.org/howtocorrupt.html > Am using C API interface for > accessing database. Is there any C API that I can use to commit my DB > manually. I know sqlite has own auto commit mechanism but it's not working > for me. > > Thanks in advance. > > -- > * > Thanks & Regards, > Rajesh Kumar P > * > ___ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] sqlite Commit C API
Hi all, Am using sqlite database on my ARM processor based Embedded system . Whenever power failures or due to uneven shutdown of device, my database is being corrupted which leading to data lost. Am using C API interface for accessing database. Is there any C API that I can use to commit my DB manually. I know sqlite has own auto commit mechanism but it's not working for me. Thanks in advance. -- * Thanks & Regards, Rajesh Kumar P * ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
