Using MS Access database as a file format for desktop application needing open / save type functionality

Question

Hello!

This is probably a pretty novice design question. I'm trying to work my way through a number of requirements and give the users the experience they're looking for...

I've written a tool that does big calcluation-type things. It currently consists of a class library and command line tool (separate .NET projects.) We're using an Access database format as the file type because it can keep all the various tables together in one file. A few other items about the application: - There are not many users. There are no concerns with scalability. - There are not great concerns with updates. - Desktop is desired. Not web. - Using VB and .NET 3.5 SP1

I now need to develop a GUI front end that will allow typical File/Open and File/Save type operations.

Users expect that they can open a file, edit it some, then either choose to save it or close it unsaved -- without any changes being written back to the file. Saving it would obviously save all changes affecting all tables back to the file.

Does it then make sense to use a temp file for something like a proxy then? To, when a user "opens" a file, copy the source Access file to a local temp file and then use that for the editing session? Then, if the user "saves", copy the local temp file back to the source path?

Is that question clear? Is the design horrid??? Any comments or suggestions?

Update: [tagged with ms-access tag too] Also, I omitted the fact that users would expect typical File / Save As functionality too. I think the design I've put in question in this post is what is traditionally called the Proxy design pattern. Has anyone tried this (successfully!) with Access database files before? Words of caution or advice?

Answer 1

Well, that approach would work, but it's not the greatest design in the world. What you're talking about is transactions, basically. A transaction is a set of operations to a database that are atomic, either they ALL go in or none of them do.

Usually, you bracket a transaction with a BEGIN and a COMMIT. That way the transaction doesn't involve the entire database, only the specific parts you're working on right then.

Hard to tell from your description though. In your case, maybe all or nothing would be ok, and the "access file copy technique" you describe would work fine.

But if the user expects to open the DB, make a few changes over here, commit them, then make a few changes over there and then undo those, it won't work well for that.