SQLite is specifically designed to protect against this. From the official SQLite is Transactional page:
All changes within a single
transaction in SQLite either occur
completely or not at all, even if the
act of writing the change out to the
disk is interrupted by
- a program crash,
- an operating system crash, or
- a power failure.
The claim of the previous paragraph is
extensively checked in the SQLite
regression test suite using a special
test harness that simulates the
effects on a database file of
operating system crashes and power
failures.
You might also be interested in the SQLite article Atomic Commit in SQLite if you need to know the specific details on how they protect against crashes such as the above.
Regarding writing after a crash: (from
File Locking and Concurrency)
A hot journal is created when a process is in the middle of a database update and a program or operating system crash or power failure prevents the update from completing. Hot journals are an exception condition. Hot journals exist to recover from crashes and power failures. If everything is working correctly (that is, if there are no crashes or power failures) you will never get a hot journal.
The worst that can happen will be that you need to delete the hot journal that is left over after a crash.