How can I update a cell value in a dB table, using SQL Server CE and C# (Visual Studio 2010)

I'm writing a small application for college, a video rental application. I have no problems reading from the database, but I cannot update the data in the tables.

In particular I'm looking to update the cell showing the quantity of a film in stock after someone rents a movie.

So far I've been trying this:

string updateDVDs = "UPDATE Products SET dvd_quantity = " + product.Quantity + " WHERE title = '"+ product.Name +"';";
cmdUpdateDVDs = new SqlCeCommand(updateDVDs, dBConnection);
dBConnection.Open();
cmdUpdateDVDs.ExecuteNonQuery();
dBConnection.Close();

I don't get any errors, but the cell doesn't update in the table. Any help would be greatly appreciated, please let me know if you require further information.

UPDATE: OK, I have some interesting developments, I have updated the code to this:

string updateDVDs = "UPDATE Products SET dvd_quantity = " + product.Quantity + " WHERE title = '" + product.Name + "'";
dBConnection = new SqlCeConnection(connectionString);
cmdUpdateDVDs = new SqlCeCommand(updateDVDs, dBConnection);
cmdUpdateDVDs.Connection.Open();
int rows = cmdUpdateDVDs.ExecuteNonQuery();
dBConnection.Close();

From what I can tell looking on MSDN both methods are valid, but this second one seems to be working. Now the weird bit, I rent the movie 'Die Hard', it all goes swimmingly, I get these results:

All good, There is no way back from this point, so I quit the application and start again. I go to rent 'Die Hard' a second time to confirm, and, success!! the new reading on the DVD quantity is 0 as expected:

But, when I open the Product table in Visual Studio the original values are still there:

Not only that, but when I run the application again after opening the table in Visual Studio the DVD quantities are reset to the original values and the updated values are gone.

Am I missing something simple here? I've tried refreshing the table, it doesn't make any difference. As long as I don't open the table in Visual Studio the application behaves as expected, no matter how many times I run it, the values update as expected, until I open the table itself.

You have to tell us exactly what connection string you are using, saying things like "I updated the connection to point to the database in the bin folder" is not helpful. Are you using a connection string like c:\Users\Me\Visual Studio 2010\Projects\MyProject\bin\debug\HKRMoviesDB.sdf? That is not right, that is hard-coded to your VS2010 debug test folder on your machine, and will not work for anyone else, will only work when you run from the debugger, and will not work when you deploy your app.

ADO.NET looks for vertical bars in connection strings and expands the enclosed string using the AppDomain property. For example, if you use Data Source=|DataDirectory|\HKRMoviesDB.sdf from the VS debugger, DataDirectory expands to your project's bin folder, where VS copies the debug DLLs. If you deploy your app using an MSI installer, DataDirectory expands to your app's install folder chosen by the user. Further explanation is at this answer.

Be aware that DataDirectory may not be a directory writable by users; it is a good directory for read-only data, but if you want users to write to the file you should copy it to Environment.SpecialFolder.ApplicationData or somewhere in your app, as explained in this answer.

There is one more thing to keep in mind. When you are debugging you typically want to copy your original source data to the debug folder, test it, then discard your test data because you typically do not want your test data included in the final deployment. This is what the "Copy to Output Directory" property in your project does. If it is set to "copy if newer", which it probably should be, then any changes you make to your test data is temporary; the next time you update your original source data in your project, your test data will be discarded. Remember, your application's deployment directory is typically not writable by users so you should not be writing user data in DataDirectory anyway.