Quote Originally Posted by jmh228
Thanks for the info guys. Let me get a handle on the new information and see if I can get it to do what I want (which is to programmatically write to the real database since I've worked out the bugs and the table's data doesn't need to change again). Then I'll change the thread to resolved.
No, no, no! I've just finished saying that you specifically do NOT want to write to your original database. It's set up to write to a copy because that's exactly what it SHOULD do. When you deploy your application you want to be able to send out a pristine database with it, not one that's full of test data or has had a bunch of test data deleted.

Basically there are two ways you'll deploy a database with an application. VS makes it very convenient to deploy a data file with your app, be it an MDF for SQL Server Express or an MDB for Access. In those cases you specifically add a database file to your app. It sits in the Solution Explorer with all the other source files. You should absolutely NOT be touching that database while testing. You should always work with a copy, and that's what VS does by default.

The other option is to use a database that is constantly attached to a server. In that case there is no source file added to your project to copy. When testing you create a database on your server yourself and that's the database you access. It doesn't matter that you only have one database full of test data though, because you won't be deploying the actual database. the end-user will use a script to create a new database on their server when they install your app, so a new database is created on the spot.