--- Kiran <[EMAIL PROTECTED]> wrote:
> This make me suspect that there is some point which
> I am missing or may be it is a defect in SQLite.
I wouldn't necessarily call a product defective simply
because it didn't behave in the manner you expected or
wished it to. Considering what I've seen when other
applications have encountered similar issues, I find
it encouraging that the engine simply went to sleep
leaving the database intact.
> Now suppose my Linux system already has a DB
> with "444" permission (say I copied from another
> Linux machine) and tried running my application,
> then I want to trap the read-only (unable to write)
> scenario.
This doesn't explain why you expect that the file
permissions may change unexpectedly. While modifying
the source code to handle the situation is a solution,
the *Nix environment already provides these tools for
you. Start your application in a shell script that
checks the file permissions before launching your
application. If you're trying to prevent others from
changing the permissions on your database, then create
a user strictly for the process accessing the SQLite
database, and ensure that the permissions are set
prohibiting other users from making modifications to
the DB file.
____________________________________________________________________________________
Yahoo! oneSearch: Finally, mobile search
that gives answers, not web links.
http://mobile.yahoo.com/mobileweb/onesearch?refer=1ONXIC
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
