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

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?

---

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.

---

The design isn't pretty I guess, but if you are using an MS Access database as a sort of "scenario" file for your calculations then this approach is the easiest to achieve what you want.

As @drventure mentioned, normally you would use transactions to control whether changes get saved or not, but in your app you would have to start a "gobal" transaction upon opening the access database and committing or abandoning that transaction depending on what the user does. I have no idea however, how Access performs handling a transaction with multiple changes on multiple tables that is "open" for a long time...

In both approaches you would have to deal with saves without closing the app? In the case of the transaction approach that is fairly simple: commit the global transaction and and immediately starting a new one. In the temporary file approach this could be a little more involved, as it would require closing and reopening the temporary file and making sure that the state of the application is preserved or re-established.