I would be tempted to create triggers to maintain a "dirty table" list
and use that to drive the copy. If you were to organize your copies in
transactions with COMMITs you would be protected from hardware failures.
If you find a way to do it without a performance hit expect a Nobel Prize
[EMAIL PROTECTED] wrote:
This is an implementation question but I am pretty sure it applies to many
people out there.
I am using a memory database which I want to "flash" periodically. I have
logically broken down the database into three pieces which have 3 degrees
of importance (critical, high and low). I have written 3 functions that
can be called to "flash" them in 3 different flash databases.
Upon system startup I am checking if these 3 databases exist and if so I
do a "create table xxx as select * from db1.xxx".
What I am doing conceptually works although I hate the way I do it. What I
am looking is the optimal solution based on the following criterion:
- I want to copy a certain number of known tables to each database
- I do not want to write to flash if the memory table is identical to the
flash table, in fact I would like to keep flash access to a minimum.
- I would like to not loose my configuration if the phone is powered down
during flash operation
- I do not want a performance hit when I flash any of these
Any suggestion, any application notes out there ?
Mario
