On 6/9/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
If you want to preserve the traditional File/Open + File/Save semantics, you could create an in-memory SQLite database then copy the disk database to the in-memory database on File/Open, and copy the other way on File/Save.
Doesn't this require loading the whole database into memory before starting?
But I have found that the traditional File/Open + File/Save paradigm leaves a lot to be desired. From a user interface perspective File/Open+File/Close is not good design. I know that most applications use that design, but they do so only due to technological limitations - limitations that are relaxed through the use of SQLite as your application file format. I find it better to directly update the database on disk. In my latest programs, I have removed File/Save. Every on-screen change is immediately written out to the application file, so there is never any reason to save. I still have File/Save_As, which makes a copy of the database and begins using the copy. And File/Open closes the current database and opens a new one. But File/Save is missing from the File menu all together.
Completely agree, with databases such as SQLite available which support ACID transactions, File/Save looks outdated. But, at the moment we are constrained to stick with File/Save. Thanks, Richard
